Lazy eval

[Sean Kelly]

Walter Bright wrote:
> Derek Parnell wrote:
>> On Mon, 21 Aug 2006 19:41:24 -0700, Walter Bright wrote:
>>
>>> Derek Parnell wrote:
>>>
>>> C++ programmers have been trying to do this for over a decade - first 
>>> with preprocessor macros, and now with expression templates.
>> And do I give a toss about C++ programming foibles ;-)
> 
> LOL! But expression templates, horrible hack that they are, are often 
> listed as the reason C++ is so powerful and therefore why should one 
> change? Expression templates are how C++ does "domain specific 
> languages" and David Abraham explains them to packed conference rooms. 
> So I believe there is a serious demand for them, but not the way C++ 
> does it, as probably only 5 people on the planet are able to create a 
> DNS using them.

In my limited experience, the attendees of those conferences are what 
I'd consider "typical" C++ programmers--they tend to use a fairly 
limited subset of the language's features and their code probably looks 
like what was popular maybe 15 years ago.  Templates are a fairly new 
thing to many of them, and many are even just getting their feet wet 
with the STL.  I would guess that Dave's presentation on expression 
templates draws a crowd for a few simple reasons: people have heard of 
Dave because he's written a book and is the front man for Boost in many 
respects, and because expression templates have a high "gee whiz" 
factor.  I think that people simply interested in learning how to write 
expression templates would go out and buy a copy of "C++ Templates: The 
Complete Guide" by D. Vandevoorde and N. Josuttis and probably not 
bother with the lecture at all.

> With the lazy evaluation thing, though, writing DNSs becomes simple and 
> straightforward, which may (just may) catapult D forward like defmac 
> rescued Lisp from oblivion.

It was simple and straightforward using the previous syntax as well. 
Though I'll grant that the "return" bit took up a bit of horizontal 
screen real estate that some might not find appealing.

> Suppose there's an API function:
> 
>     void anotherFunc(int x);
> 
> which I call:
> 
>     int y = 3;
>     anotherFunc(y);
>     writefln(y);
> 
> then the library writer changes the API to:
> 
>     void anotherFunc(inout int x);
> 
> and internally increments x. I'm left wondering why 4 is now being 
> printed instead of 3.

But that would be a blatant change in behavior for the API function, 
while converting to a delegate parameter is arguably not a change in 
behavior, just in the way the value is being transferred.  It's probably 
also worth noting that in a language supporting const features, 
switching an in param to inout would probably result in compile errors 
in at least a few uses of the function.

That aside, it may be worth noting that this new delegate syntax has 
some small potential for faking const behavior in D, though it would 
likely make a mess of code attempting this.


Sean