range and algorithm-related stuff

[Andrei Alexandrescu]

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