lazy thoughts

[Jason House]

Andrei Alexandrescu Wrote:

> bearophile wrote:
> > Andrei Alexandrescu:
> >> I'll wait for bearophile to tell if he feels he hasn't gotten the
> >> credit he believes he deserves before I answer this particular
> >> point.
> > 
> > I'm having a bad week for matters unrelated to D. You are doing lot
> > of work for D, so don't worry for me. I was just a bit sad seeing you
> > inventing some things I use often and I have shown here few times.
> > 
> > Consider the idea of having both lazy/eager versions of your
> > functors.
> > 
> > Consider the idea of having a functionality like the xchain functor
> > and Chainable class mixin of my libs (that is lazy chaining of
> > arbitrary iterables, eager and lazy) using ~.
> > 
> > I have also created various other things that you may re-invent in
> > the following days and weeks, like the Xcast, a way to cast lazily
> > the items of an iterable, etc.
> > 
> > One small but important thing I think has to be fixed in D2 is
> > related to associative arrays in D: iteration has to happen first of
> > all on keys. This gives big practical advantages. In my libs all
> > functions when confronted with AAs use their keys first.
> > 
> > In my dlibs I have implemented several other things that I hope to
> > see in D2, like the record/Record that is a much better Tuple, a
> > better equality testing among arrays, testing and comparison among
> > associative arrays, etc. I have explained such things few times, but
> > I am willing to explain them again, if there's someone willing to
> > listen.
> 
> I understand. It would be great to solve this to everybody's 
> satisfaction, and I think it's entirely possible.
> 
> First off, allow me a rather general comment stemming from experience. 
> The problem with little ideas like that is exactly that they are little 
> - they are often hard to give credit for, and they may occur 
> independently to many people. Over time I've shared many such little 
> ideas with the C++ community in various venues, and I've often found 
> them used without credit. The true solution is simply to let that go and 
> hunt for bigger ideas. Bigger ideas have more impact, have larger uses, 
> and are less likely to occur to others independently.
> 
> Second, you'd hopefully give me that I'd heard of the benefits of lazy 
> evaluation before having joined this group. The reason today's 
> std.algorithm forgoes lazy evaluation is that iterating lazy structures 
> is either very cumbersome (proxies) or very inefficient (opApply). 
> Cumbersome abstractions will hardly become popular, and I hold costly 
> abstractions in utter contempt. They are a dime a dozen and putting them 
> straight in the core language and/or standard library would surely 
> hamstring everything using them in actuality or in spirit. (Alan Perlis: 
> "Lisp programmers know the value of everything and the cost of nothing." 
> Well that has changed in modern Lisp because the prevalence of macros 
> has grown appropriately, but it's still funny.) That's why the real 
> problems to solve were things like figuring out an efficient way to 
> define higher-order functions (via alias usage versus slow delegate 
> usage), a solid iteration abstraction, and rendering opApply obsolete. 
> That was the hard problem, not implementing higher-order functions or 
> lazy algorithms. Once the solution was in place, the door is open for 
> all sorts of cool stuff, and here's where you can add beneficial influence.
> 
> This brings me to a third issue. If you want to make dlibs popular, 
> talking about it on the newsgroup is a very inefficient way. Many 
> discussions come and go on the newsgroup. I seem to remember that for 
> the longest time you only provided your library as a downloadable zip 
> file (with html documentation *inside* the zip). I want you to sit for a 
> minute and ponder about the obtuseness of such a setup. It's almost like 
> you wanted to just make a token acknowledgment of your own work, while 
> keeping it in fact thoroughly obscure. Then, after finally having put 
> the library online (at my behest as far as I remember), its online 
> documentation could stand significant improvement and examples. You 
> could do so with a fraction of the effort you spend on this newsgroup 
> e.g. explaining your putr function (which, as expected, came and went 
> and is now largely forgotten). If I were you I'd probably add some nice 
> examples to the documentation and put a link to it in my .sig. Then, 
> whenever you want to make a point, you can simply refer people to links 
> to your documentation and examples, instead of sitting down and writing 
> rationale and examples every time the discussion comes close.
> 
> 
> Andrei

Point #3 is on the mark. A URL to quality documentstion is worth 100 posts declaring the superiority of dlibs.