Notes on D future

[bearophile]

Reiner Pope:

>Presumably just an annotation like "pure" on the function should be enough:<

I don't know if the compiler is able to enforce this, I hope so, otherwise it may become a source of bugs.


--------------------------

I have seen they are talking about those D future slides on the very good Lambda the ultimate Blog:
http://lambda-the-ultimate.org/node/2421
Three of those notes:

>[D is] Not quite functional either. D's closures are broken.
The environment of a nested function points to the outer function's stack and continues to do so after the outer function has returned. When a dynamic closure is called, its vars may refer to a now defunct part of the stack (or worse, belonging to some other call). Horrors.
Unfortunately, it isn't merely a problem with the implementation; it is explicitly mentioned in the language reference.
I like many of the language's features. However, looking at the slides, I can't escape the feeling that this is another Groovy-style language kitchen sink in the making.<

Q: >Is a reson for this design choice given, or is this simply an error that worked its way into the specification?<

A: >No, there are no reasons given.
I have the utmost respect for Walter Bright. I suspect, however, that the essential mindset behind the requirements and design is that one shouldn't lose any performance ground to C/C++, and it would be undesirable to go to the heap to allocate a closure.

All speculations, of course. The D folks have run into this problem already and it may be fixed.<


I can see some "solutions":
1) Do nothing. D is a system programming language that tries to be close to the metal as C, so the programmer has to accept some compromises to be able to write fast code.
2) D has "function" and "delegate", so maybe a third annotation can be used to tell the compiler to use a differen semantics, so such functions can be passed around like closures (like you do in Scheme).
3) Global (top) functions and nested functions can become even more different. So if the programmer wants C-like speeds shi/he/she has to use only global functions (like in a C program), if she/he/shi wants to use nested functions (that allow the creation of closures too) then he/she/shi has to accept to go slower.


Regarding the "kitchen sink" problem: I think it's not a problem, it's a positive point. It's better to solve a problem using in a shallow way one of many tools than using in deep way one of few powerful and general tools. Because in the fist case the programmer needs less brain, can produce the code faster, and it's less likely to put bugs in (if the libraries are bug-free enough). So I appreciate the style of D of putting lot of things in. I'd even like to see more built-in stuff, like sets, dynamic multidimensional matrixes contiguously allocated, yield, lazy constraint-based programming, and more features for parallel programming taken from Fortress language designed by Sun. :-)

Bye and thank you,
bearophile