lazy evals + parameter passing

Jari-Matti Mäkelä jmjmak at utu.fi.invalid
Mon Sep 4 13:37:17 PDT 2006


Chris Nicholson-Sauls wrote:
> Jari-Matti Mäkelä wrote:
>> I think it's fully possible by introducing |par1, ..., parn | syntax
>> so that
>>
>> { | a, b | a+b }
>>
>> would be the same as
>>
>> int _anonymous(inout a, inout b) {
>>   return a+b;
>> }
>>
>> What do you think? Does it look ugly? Doesn't it offer a great deal of
>> new functionality. I think we really NEED this - please Walter, make it
>> pre-1.0 :)
> 
> First, D's interesting new Lazy feature is really not like Ruby's Block
> feature at all

No, but it's pretty near.

> Instead, Lazy is primarily about affirming that
> an expression will not be evaluated until it is neccessary to do so.  In
> other words, that you could for example pass a complicated string
> expression to a function which MAY or MAY NOT output that string
> somewhere.  Lazy evaluation promises you that the string won't get
> processed unless that function DOES output it.

> That noted, of course, they do behave essentially as delegates (and
> internally ARE delegates I believe) and so the given expression MAY be
> evaluated multiple times.  One would have to note the documentation for
> the function in question before relying on or protecting against any
> side effects.

I guess this has been discussed before, but I'm still curious - why are
they separate? Is it because there is no syntax for parameter passing or
does it cause extra overhead to support full features of delegates when
only a small subset is mostly needed?

> Second, the new anonymous delegate syntax already gives us more-or-less
> what you want except for two missing items: a delegate body containing
> nothing but an expression should get an implicit 'return ... ;' wrapped
> around it, yielding capability.
> 
>     { | a, b | a + b }
> is actually
>     (a,b){ a + b }

Ah, thanks. It was a bit hidden in the docs but now I found it. This
feature really rocks.

> I'm also not positive if type inferance would handle this case or not,
> so it may more correctly be:
>     (int a, int b){ a + b }

This one works.



More information about the Digitalmars-d mailing list