BCS wrote:
> Walter Bright wrote:
>> I was going to call this 1.0 RC1, but I just could not resist adding the lazy expression evaluation. This adds one of the big capabilities of common lisp.
>>
>> http://www.digitalmars.com/d/changelog.html
> 
> cool, I like it
> 
> given
> 
> void foo(char[]);
> void foo(char[] delegate());
> 
> how do I force the use of  the first?

You can't. Think of it like:

void foo(in int x);
void foo(out int y);
void foo(inout int z);

Can't force the use of one of those, either.

Walter Bright wrote:
> BCS wrote:
> 
>> Walter Bright wrote:
>>
>>> I was going to call this 1.0 RC1, but I just could not resist adding the lazy expression evaluation. This adds one of the big capabilities of common lisp.
>>>
>>> http://www.digitalmars.com/d/changelog.html
>>
>>
>> cool, I like it
>>
>> given
>>
>> void foo(char[]);
>> void foo(char[] delegate());
>>
>> how do I force the use of  the first?
> 
> 
> You can't.
> 

Ouch!

That could be bad where the evaluation of the expression has side effects or is time (when not how long) critical.

volatile char* vcp;
log("data is now: "~(vcp[0..10].dup));

Will the (char[]) form ever get called?

Any expression can be converted into a anon-delegate, so anything that would work for the first, also works for the second. How is one picked over the other?

This seems to be an "oddity" in the overload rules.

Walter Bright wrote:

>> Will there be a "Beta" period, between the current Alphas and Release ?
> 
> I don't think there's a need for a beta period.

Maybe just a quick breather then, to let GDC catch up ? :-)

Specifically I was talking about a "feature freeze" time.

> D's already in heavy use, we know what state it's in.

Or "was in", just finished updating my import statements...

(didn't notice on my GDC, since it was at DMD 0.162 still)

--anders

Walter Bright wrote:
> Sean Kelly wrote:
>> Walter Bright wrote:
>>> I was going to call this 1.0 RC1, but I just could not resist adding the lazy expression evaluation. This adds one of the big capabilities of common lisp.
>>>
>>> http://www.digitalmars.com/d/changelog.html
>>
>> Is there any chance my post entitled "No way to selectively expose imported symbols using 163" in d.D could be addressed or at least considered before RC1?  It would have a slight impact on the wording describing selective import if so.  Here is a direct link to the post:
>>
>> http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=40811 
> 
> I think that's just a compiler bug, not a design problem.

Just wanted to make sure, since this would affect the wording in the spec :-)


Sean

Walter Bright wrote:
> Sean Kelly wrote:
>> Walter Bright wrote:
>>> I was going to call this 1.0 RC1, but I just could not resist adding the lazy expression evaluation. This adds one of the big capabilities of common lisp.
>>>
>>> http://www.digitalmars.com/d/changelog.html
>>
>> Nice work!  I'm not sure I understand the advantage offered to the enforcement example however, unless it is in creating the message string (a benefit that was already demonstrated).  Where is the lazy evaluation occurring?
> 
> The example has typos in it, but the advantage is to not evaluate the msg (which can be arbitrarily complex) unless an error actually occurs.

Thanks.  I suppose it's worth mentioning that lazy evaluation can result in some confusing errors similar to those encountered with macro functions vs. normal functions.  For example:

    void fn( char delegate() ch )
    {
        if( ch() == 'c' || ch() == 'd' )
        {
            printf( "match\n" );
        }
    }

    size_t pos = 0;
    char[] buf = "abdc";

    fn( buf[++pos] );

The above code would print "match" because pos would be incremented twice.  This makes API changes from the classic to lambda syntax a risky venture, as it risks silently breaking once-working code.


Sean

Anders F Björklund wrote:
> Walter Bright wrote:
> 
>>> Will there be a "Beta" period, between the current Alphas and Release ?
>>
>> I don't think there's a need for a beta period.
> 
> Maybe just a quick breather then, to let GDC catch up ? :-)
> 
> Specifically I was talking about a "feature freeze" time.
> 
>> D's already in heavy use, we know what state it's in.
> 
> Or "was in", just finished updating my import statements...
> 
> (didn't notice on my GDC, since it was at DMD 0.162 still)

I was careful to do the lazy evaluation entirely in the front end, so integration with GDC should be as easy as possible.

Sean Kelly wrote:
> Thanks.  I suppose it's worth mentioning that lazy evaluation can result in some confusing errors similar to those encountered with macro functions vs. normal functions.  For example:
> 
>     void fn( char delegate() ch )
>     {
>         if( ch() == 'c' || ch() == 'd' )
>         {
>             printf( "match\n" );
>         }
>     }
> 
>     size_t pos = 0;
>     char[] buf = "abdc";
> 
>     fn( buf[++pos] );
> 
> The above code would print "match" because pos would be incremented twice.  This makes API changes from the classic to lambda syntax a risky venture, as it risks silently breaking once-working code.

It doesn't break existing once-working code, because the example shown will not compile with 0.164 and earlier compilers.

Walter Bright wrote:
> Sean Kelly wrote:
>> Thanks.  I suppose it's worth mentioning that lazy evaluation can result in some confusing errors similar to those encountered with macro functions vs. normal functions.  For example:
>>
>>     void fn( char delegate() ch )
>>     {
>>         if( ch() == 'c' || ch() == 'd' )
>>         {
>>             printf( "match\n" );
>>         }
>>     }
>>
>>     size_t pos = 0;
>>     char[] buf = "abdc";
>>
>>     fn( buf[++pos] );
>>
>> The above code would print "match" because pos would be incremented twice.  This makes API changes from the classic to lambda syntax a risky venture, as it risks silently breaking once-working code.
> 
> It doesn't break existing once-working code, because the example shown will not compile with 0.164 and earlier compilers.

I was thinking more of converting an API call from:

    void fn( char ch );

to:

    void fn( char delegate() ch );

Both accept the same parameters under DMD 165, but the result may be different.  But this is something library developers simply must keep in mind more than a problem with the technique itself.  It would be easy enough to document how the supplied delegate is evaluated.


Sean

> It doesn't break existing once-working code, because the example shown will not compile with 0.164 and earlier compilers.

It does if you had before both:
void fn( char delegate() ch ){...}
void fn( char ch ){...}

is now ambiguous for the call, so the only option is to remove the second proto.

BCS wrote:
> Walter Bright wrote:
>> BCS wrote:
>>> given
>>>
>>> void foo(char[]);
>>> void foo(char[] delegate());
>>>
>>> how do I force the use of  the first?
>> You can't.
> Ouch!
> 
> That could be bad where the evaluation of the expression has side effects or is time (when not how long) critical.
> 
> volatile char* vcp;
> log("data is now: "~(vcp[0..10].dup));
> 
> Will the (char[]) form ever get called?

It won't compile, as it'll give an ambiguity error.

> Any expression can be converted into a anon-delegate, so anything that would work for the first, also works for the second. How is one picked over the other?
> This seems to be an "oddity" in the overload rules.

It just gives an ambiguity error at compile time.