View mode: basic / threaded / horizontal-split · Log in · Help
August 21, 2006
Re: DMD 0.165 release
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.
August 21, 2006
Re: DMD 0.165 release
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.
August 21, 2006
Re: DMD 0.165 release
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
August 21, 2006
Re: DMD 0.165 release
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
August 21, 2006
Re: DMD 0.165 release
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
August 21, 2006
Re: DMD 0.165 release
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.
August 21, 2006
Re: DMD 0.165 release
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.
August 21, 2006
Re: DMD 0.165 release
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
August 21, 2006
Re: DMD 0.165 release
> 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.
August 21, 2006
Re: DMD 0.165 release
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.
1 2 3 4 5 6 7 8
Top | Discussion index | About this forum | D home