No subject

>I know it's a matter of balance. I am not sure what gave you the idea that I didn't.<

Probably your balance seems toward more complexity than I like to have in a language. I presume Walter will follow your advice, but a too much complex language (even if more powerful and more efficient than the current D) may not be what most people look for. We'll see if I'm right.
I'm not good enough yet to design a language, so I have to leave you the work :-)


>I think many would agree that foreach minus the disadvantages would be better.<

Only if the increase in complexity for this specific thing is perceived by most D programmers as less important than the improvement in performance and flexibility, of course :-)


>How do I know that? Because I measured. Why did I measure? Because I care. Why do I care? Because the typical runtime of my programs measure in hours of sheer computation, and because things like reduce and others in std.algorithm are in the core loops. And I am not alone.<

I can see there's a large difference in purposes here, while I too care and I too have written few thousands of lines of code to benchmark most things I have written, the point of my functional stuff lib is mostly to replace code that's not in core loops, it's designed to improve coding for the 80-90% of the code where performance isn't so important.


>Costly abstractions are a dime a dozen. It's efficient abstractions that are harder to come across.<

I have understood this only after reading long texts by Alexander Stepanov regarding the STL :-) That's where I have gained respect for the STL and the C++ language, and their designers.

But elsewhere I have also realized that in a very large percentage of lines of code in a program (80%?) you don't need max performance, and in such parts of the code there are other things that deserve to be maximized: succinctness of code, flexibility, usage simplicity, adaptability to a large number of situations, anti-bug-prone coding, etc. About the same qualities a built-in data structure like the Associative arrays is useful for. Paying the price that comes from code that strives for max performance in the whole program leads to lot of brainpower required to write the code, very complex bugs, etc.


>If you believe I am wasting time with cutesies in std.algorithm, please let me know of the places and of the suggested improvements.<

There are few things I don't like there, but nothing major :-)
Time ago I have posted something in the main D newsgroup, I think few things are changed in the meantime (I think Walter has improved max/min):

http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=67113


>I agree.<

Oh good, then you may agree with me that the langage too may enjoy to have some ability to "scale down" :-)


>To quote a classic, Lisp has had them all for 50 years.<

But Python syntax is few lightyears ahead compared to CLisp ;-)


>I plan to implement things like lazyMap and lazyReduce,<

I presume the large body of (refined) code I have already written on this in my libs is useless to you, because it's based on opApply... But maybe you can find use in few names, some argument lists, etc (In the next days I have some of that code to show to Walter, but it becomes even more useless for Walter now).

Thank you for the patience and your kind answers,
bye,
bearophile