bearophile wrote:
Andrei Alexandrescu: You can take a look at my dlibs, they may give
you ideas, because contain all such lazy functions and some more.
You mean the libs in my signature? Sure. :o)
In http://www.fantascienza.net/leonardo/so/dlibs/func.html, I like
functions such as any and all; they aren't readily implementable by
combining other primitives. Predicates will be passed as aliases though.
Probably array and assign will make the cut as well. I like frequency a
lot, would be very useful for my NLP code (although probably I'd replace
it with counts and let the user normalize). Other are already present in
similar forms and sometimes with different names (but I think that e.g.
"chain" is better than my "span").
I presume you have chosen to not tell apart the lazy functions from
the eager ones.
Well, so far it's been pretty clear what should be lazy and what
shouldn't, e.g. map is lazy and reduce is eager :o). Also, signature can
also distinguish rather easily between lazy and eager. For example, you
have lazyAnd and lazyOr, but there's no necessity for eagerAnd and
eagerOr; those would be rather silly. You do have all and any, which is
eager (in a sense), but also has a signature that makes it not compete
with lazyAnd and lazyOr.
2. take(n, range) => takes at most n elements out of a range (very
useful with infinite ranges!)
I think that an xslice is better than an xtake (it's essentially a
lazy version of a more powerful version of the slicing that in D you
can do on arrays).
The problem with xslice is that it has a O(n) setup time on a input or
forward range, and that that cost is somewhat hidden in a
non-decomposable manner. People who need something like slice can call
drop to advance the range in documented linear time, and then use take.
Andrei
--
http://www.fantascienza.net/leonardo/so/dlibs/all.html
