• bearophile <bearophileHUGS lycos.com> Jan 25 2009
• Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> Jan 26 2009
• bearophile <bearophileHUGS lycos.com> Jan 26 2009
• bearophile <bearophileHUGS lycos.com> Jan 26 2009
• Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> Jan 26 2009

bearophile <bearophileHUGS lycos.com> writes:

Andrei Alexandrescu:
You can take a look at my dlibs, they may give you ideas, because contain all
such lazy functions and some more.

I presume you have chosen to not tell apart the lazy functions from the eager
ones.


 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).

Bye,
bearophile

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

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

bearophile <bearophileHUGS lycos.com> writes:

Andrei Alexandrescu:

 You mean the libs in my signature? Sure. :o)


:-]


 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).


It doesn't perform a normalization (I can add to it few more functionalities
can be added, but not this one), I'll improve its documentation.


 Also, signature can also distinguish rather easily between lazy and eager.


Well, if you are using an IDE that's easy. Otherwise you may need your memory
or a manual.


Several of my lazy functions are inspired by:
http://docs.python.org/library/itertools.html

I don't like to show people programs that require my large dlibs to run, so I
hope 80-90+% of my dlibs will be obsolete in D2.

D2 supports immutable data structures, so the D Std lib may gain some immutable
data structures, like finger trees, etc.

Multi-threading, pure functions, immutable data structures, and lazy
computations are forms of computation quite different from the usual ones done
in C. I am sure the current D2 Std lib is using only a small part of the
potential usages of such programming styles :-) I think some of such usages
have yet to be invented (when C++ developers have added templates to C++ surely
they didn't know all the weird and creative usages of them used for example in
Blitz++ or Boost).

Seeing the work of Walter, your work here, and the community in this newsgroup,
and on the other hand seeing how a significant percentage of computer science
is done in academy, and what it produces, I'd say that there's more innovation
and creativity here :-) Lot of CS is out of the world, not doing useful things,
and sometimes not even much intelligent.
Yet, I know many smart folks working in CS in academy, and I think the design
of D2 may be improved by some "hard" thinking done by that researchers. It's a
pity there are so little communication between the two groups.

Bye,
bearophile

bearophile <bearophileHUGS lycos.com> writes:

bearophile:
 and sometimes not even much intelligent.


I meant: "sometimes not even much interesting."

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

bearophile wrote:
 Andrei Alexandrescu:
 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).


 It doesn't perform a normalization (I can add to it few more
 functionalities can be added, but not this one), I'll improve its
 documentation.


Oh, it's the name that threw me off. I automatically assumed that 
"frequency" is normalized counts.

 Several of my lazy functions are inspired by: 
 http://docs.python.org/library/itertools.html
 
 I don't like to show people programs that require my large dlibs to
 run, so I hope 80-90+% of my dlibs will be obsolete in D2.
 
 D2 supports immutable data structures, so the D Std lib may gain some
 immutable data structures, like finger trees, etc.
 
 Multi-threading, pure functions, immutable data structures, and lazy
 computations are forms of computation quite different from the usual
 ones done in C. I am sure the current D2 Std lib is using only a
 small part of the potential usages of such programming styles :-) I
 think some of such usages have yet to be invented (when C++
 developers have added templates to C++ surely they didn't know all
 the weird and creative usages of them used for example in Blitz++ or
 Boost).
 
 Seeing the work of Walter, your work here, and the community in this
 newsgroup, and on the other hand seeing how a significant percentage
 of computer science is done in academy, and what it produces, I'd say
 that there's more innovation and creativity here :-) Lot of CS is out
 of the world, not doing useful things, and sometimes not even much
 intelligent. Yet, I know many smart folks working in CS in academy,
 and I think the design of D2 may be improved by some "hard" thinking
 done by that researchers. It's a pity there are so little
 communication between the two groups.
 
 Bye, bearophile


That's good to read, and a definite departure from your discouragement 
of a few weeks ago. I agree, there are vast areas as of yet unexplored 
in D2, and compile-time introspection will open up even many more. (By 
the way, I figured how to do introspection, I need to discuss details 
with Walter and Sean after which it'll be "a simple matter of 
implementation".)

I agree that run-of-the-mill academic work may not be that good, but 
then there's a lot of run-of-the-mill practitioner work. I'd say our 
work on D2 as of now is not quite up to par with top academic work. The 
communication is mostly due to us doing little to publicize D2. But that 
will improve starting soon.


Andrei