Frank Benoit wrote:
>> 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.

That's right.

Sean Kelly wrote:
> 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.

That's true, but I expect the library developer to be cognizant of how his changes affect user code, and make the right choices.

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


We could already do "lazy expression eval" in D, using dmd164 delegates; sans new sugar. So that Lisp ability was already present?

I like a bit of sugar as much as anyone, especially when it's part of some classy dark-chocolate. But there's some practical issues with this most recent syntactic sugar. The overload issue is a real one, and the added complexity of having to manually check a callee declaration before you can grok what happens to an expression arg will also become a realisitic problem. Particularly so when you happen to miss a method overload in some subclass somewhere.

In this specific case, I suspect there needs to be an indication of some kind, at the call site, to clearly and unambiguously communicate to a person (and to the compiler) exactly what is going on. Otherwise, this may be just the kind of sugar that rots the teeth of D ?

On Mon, 21 Aug 2006 11:06:12 -0700, 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. 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.

But why is that *not* a problem with the language?

-- 
Derek Parnell
Melbourne, Australia
"Down with mediocrity!"

On Mon, 21 Aug 2006 12:47:01 -0700, Walter Bright wrote:

> Frank Benoit wrote:
>>> 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.
> 
> That's right.

And yet so wrong too.

-- 
Derek Parnell
Melbourne, Australia
"Down with mediocrity!"

Derek Parnell wrote:
> On Mon, 21 Aug 2006 12:47:01 -0700, Walter Bright wrote:
> 
>> Frank Benoit wrote:
>>>> 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.
>> That's right.
> 
> And yet so wrong too.

That would be so wrong if such overloads were common. But I can't think of much of any cases where one would want to write such overloads.

Derek Parnell wrote:
> On Mon, 21 Aug 2006 11:06:12 -0700, 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. 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.
> 
> But why is that *not* a problem with the language?

A good question. I think the answer is that one would be want to overload based on in/out/inout only to write obfuscated code.

kris 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
> 
> 
> We could already do "lazy expression eval" in D, using dmd164 delegates; sans new sugar. So that Lisp ability was already present?

Yes. But few to nobody noticed it, and I'll posit that this bit of sugar will expand its use by a couple orders of magnitude.


> I like a bit of sugar as much as anyone, especially when it's part of some classy dark-chocolate. But there's some practical issues with this most recent syntactic sugar. The overload issue is a real one, and the added complexity of having to manually check a callee declaration before you can grok what happens to an expression arg will also become a realisitic problem. Particularly so when you happen to miss a method overload in some subclass somewhere.

D (and other languages) already have that with in, out, inout, implicit conversions, all the proposals for const, mutable, and other storage classes. C++ has it for reference types, const types, implicit conversions, etc. You already cannot tell what is happening with the arguments without looking at the prototype.

I'll also point out that C/C++ programs routinely use macros to do the equivalent (and much worse).


> In this specific case, I suspect there needs to be an indication of some kind, at the call site, to clearly and unambiguously communicate to a person (and to the compiler) exactly what is going on.

There already was (and is) in the form of { return exp; }. It's just not accepted - I can hardly count all the comments I get from people saying D didn't support this capability, and when I point out the { return exp; }, they frown like people do when you tell them broccoli is good for them.

> Otherwise, this may be just the kind of sugar that rots the teeth of D ?

Maybe, but I haven't seen any food stores carry the Odwalla vegetable juice for years <g>.

I do understand your concern, and I think I understand the issues. Only time and experience will tell us definitively if this is the right move or not, but my gut tells me it is. I *do* know that this has a "gee whiz" aspect to it that gets peoples' attention, and that's good for D to help it develop its own clear place in the panopoly of programming languages.

Walter Bright wrote:
> kris 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
>>
>>
>>
>> We could already do "lazy expression eval" in D, using dmd164 delegates; sans new sugar. So that Lisp ability was already present?
> 
> 
> Yes. But few to nobody noticed it, and I'll posit that this bit of sugar will expand its use by a couple orders of magnitude.
> 
> 
>> I like a bit of sugar as much as anyone, especially when it's part of some classy dark-chocolate. But there's some practical issues with this most recent syntactic sugar. The overload issue is a real one, and the added complexity of having to manually check a callee declaration before you can grok what happens to an expression arg will also become a realisitic problem. Particularly so when you happen to miss a method overload in some subclass somewhere.
> 
> 
> D (and other languages) already have that with in, out, inout, implicit conversions, all the proposals for const, mutable, and other storage classes. C++ has it for reference types, const types, implicit conversions, etc. You already cannot tell what is happening with the arguments without looking at the prototype.
> 
> I'll also point out that C/C++ programs routinely use macros to do the equivalent (and much worse).
> 
> 
>> In this specific case, I suspect there needs to be an indication of some kind, at the call site, to clearly and unambiguously communicate to a person (and to the compiler) exactly what is going on.
> 
> 
> There already was (and is) in the form of { return exp; }. It's just not accepted - I can hardly count all the comments I get from people saying D didn't support this capability, and when I point out the { return exp; }, they frown like people do when you tell them broccoli is good for them.


Yes; would be nice to eliminate the return and the secondary ';' so it looks like

# somefunk ({++i});
#
# rather than
#
# somefunk ({return ++i;});

Quite a difference, and both are still explicit rather than introducing ambiguity. Or, use some kind of operator instead, like c# does?

# somefunk (=> ++i);


> 
>> Otherwise, this may be just the kind of sugar that rots the teeth of D ?
> 
> 
> Maybe, but I haven't seen any food stores carry the Odwalla vegetable juice for years <g>.
> 
> I do understand your concern, and I think I understand the issues. Only time and experience will tell us definitively if this is the right move or not, but my gut tells me it is. I *do* know that this has a "gee whiz" aspect to it that gets peoples' attention, and that's good for D to help it develop its own clear place in the panopoly of programming languages.


Perhaps ;)

I should point out that any and all of that "Gee Whiz" will be immediately countered with a "Hrm, there's a lot of ambiguity here", as you've seen already from those who are perhaps the biggest supporters of D

The detractment of ambiguity should not be underestimated, and can be surely be avoided (in this case) with an adjustment here or there?

Walter Bright wrote:
> Derek Parnell wrote:
> 
>> On Mon, 21 Aug 2006 11:06:12 -0700, 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. 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.
>>
>>
>> But why is that *not* a problem with the language?
> 
> 
> A good question. I think the answer is that one would be want to overload based on in/out/inout only to write obfuscated code.

but the lazy vs. non-lazy question isn't so simple


log(RunSQLStuff());

vs.

log("This is a string");


???