[m-dev.] Laziness modules

[Peter Moulder]

On Tue, May 05, 2009 at 05:04:53PM +1000, Ralph Becket wrote:
> I put a couple of modules providing support for lazy computation
> together at the weekend.  Is there any interest in adding these to the
> library?  Laziness gives us what in the C# and Java worlds they call
> "enumerables" and are using to good effect.

Can you comment on how this compares with mercury-extras/lazy_evaluation/ ?

It looks like the two use different names for the same concepts; it would be
good to change the two to share names (perhaps leaning slightly towards
choosing lazy_evaluation's names, to the extent that we think users of your new
module may already have used lazy_evaluation).

The documentation in lazy_evaluation largely applies to both, but it would be
good to draw attention to any differences.


I'm afraid I haven't looked carefully at the lazy implementation itself; the
remainder of this message pertains to the less important stuff, the lazy_list
module.

I notice that lazy_list.take (both in lazy_evaluation and the newer version)
corresponds to list.take_upto rather than list.take.  That seems unfortunate.

Similarly lazy_list.drop (in the new version; not present in lazy_evaluation).

lazy_list.take_while doesn't exactly correspond to list.takewhile:
list.takewhile is a predicate and has an additional AfterList argument
(the rest of the list).  However, I think I'd ignore list.takewhile here.

ints: Consider either documenting that the result is undefined if Hi is
int.max_int, or make it work if Hi is int.max_int.

ints_with_step:

  Similar issue as with ints, except there are more Hi values with that issue if Step > 1.

  The documentation is unclear, btw: a literal reading is that Max = Hi.  (Adding
  the word `such' would suffice for me.)

  Also, my reading of the documentation is that ints_with_step(10, 1, -1) returns
  a non-empty list.

  However you resolve that, consider explicitly drawing attention to the behaviour
  if Step is non-positive.

  Copy-and-paste bug s/ints/ints_with_step/ in documentation.

  Consider using Mercury-style `=<' rather than `<=' in the documentation.

(I wouldn't bother mentioning int_max in documentation for ints_from or
 ints_from_with_step: in this case it follows from the general principle of
 overflow behaviour being undefined for Mercury int's, whereas I do think it
 worth mentioning for ints and ints_with_step because (a) whether or not
 overflow occurs in ints or ints_with_step is an implementation detail; and
 (b) it's relatively common to want to pass max_int for ints-like predicates.)


> multiple_of(X, Y) :- Y mod X = 0.

Suggest s/mod/rem/.  (I know it's intended to be simple rather than efficient,
but I don't consider mod as clearly simpler than rem.  Though I've no strong
objection to mod if you prefer it.)


pjrm.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at csse.unimelb.edu.au
Administrative Queries: owner-mercury-developers at csse.unimelb.edu.au
Subscriptions:          mercury-developers-request at csse.unimelb.edu.au
--------------------------------------------------------------------------