Lazy eval -- an example issue

[kris]

Walter Bright wrote:
> kris wrote:
> 
>> Walter Bright wrote:
>>
>>> Just get rid of the (char[]) versions. You could argue "what about 
>>> the efficiency?"
>>>
>>> 1) Passing a delegate is exactly the same number of instructions as 
>>> passing a char[], i.e., it is two values being passed.
>>>
>>> 2) Actually calling the dg() will, of course, cost more instructions 
>>> than just referencing a []. This is mitigated by, presumably, logging 
>>> being normally off, and being overshadowed by the rest of the actual 
>>> logging cost.
>>>
>>> 3) It is possible that the delegate can be inlined, thus eliminating 
>>> any extra overhead.
>>
>>
>>
>> lol! I can just imagine 1001 log statements inlined within the log 
>> code ;D
>>
>> There's a fairly significant overhead in making a callback. Just as 
>> much, or more, than handling a significant proportion of log-messages 
>> themselves (I find a significant number to be static text; not 
>> contructed dynamically). In addition, if the compiler can't prove 
>> these logging delegate do not escape, each hosting function may well 
>> have their frames allocated on the heap ... we've been discussing that 
>> just recently.
> 
> 
> I've been thinking a lot about the escape problem. I'm pretty sure that:
>     char[] delegate() { return "foo"; }
> can be detected and so I can assure you it won't cause the enclosing 
> function's variables to be allocated on the heap.
> 
>> All this because you insist programmers can't be bothered to add a 
>> tiny bit of syntax (even optionally) to clarify the intent? This is 
>> madness!
>>
>> Utter madness. Please restore some sanity here.
> 
> 
> Calling it 'madness' is blowing things way out of proportion. (And you 
> still can use the { } syntax like before.)

Asserting "programmers won't type the {}" as the reason for deliberate 
introduction of ambiguous syntax is throwing caution to wind; in the 
extreme. Any for what? There's not even any evidence to uphold that 
assertion. You didn't even bother with a poll of the people who actually 
use delegates ...

To me, that's madness. Marketing is clearly in the driving seat, and you 
apparently won't even consider other options.


> 
>> Why don't you conduct a poll asking exactly which 'programmers' won't 
>> use the {} delimeters to unambiguously declare a delegate?
> 
> 
> I've struggled to get people to accept the {} version ever since D 
> adopted anonymous delegates. Haven't made much headway in getting such 
> used or in it having any sort of significant impact. How many have made 
> a "dotimes(n, exp)" function or any sort of syntax extension using it? 
> None that I've seen.

How do you know this? Where exactly does your information come from, and 
how is it measured?


> 
> It's sort of like the itunes. Apple didn't invent anything new. They 
> just removed a couple annoying button pushes, and voila, suddenly the 
> handheld music player gained traction.
> 
> I hesitate to use argumentum ad verecundiam because it's a logical 
> fallacy, so you can take the following for what it's worth. Andrei and I 
> certainly have our differences of opinion. But when I disagree with him, 
> I'd better have done my homework, or I'll get cut to pieces. He thinks 
> (and he obviously convinced me) that removing the { } makes all the 
> difference.

Perhaps Andrei doesn't write much D, or perhaps he's just wrong? Either 
way, you've deliberately introduced a serious syntactic ambiguity. 
That's going to cause notable detractment, and for good reason.


> 
> I want to give it a fair shot. It has potential to be a big win for D, 
> and the consequences of it being a mistake are small. How many here have 
> experience with defmac in Common Lisp, or something equivalent? I sure 
> don't, but people who use CL successfully say it's huge.

It is, but you don't lose anything in usability by typing the curly 
parens (or some other operator/indicator). Plus the ambiguity would not 
exist.

Some say Paris Hilton is "famous for being famous" -- perhaps one of the 
most empty accomplishments one could possibly achieve. What we 
apparently have here is ambiguity for the sake of ambiguity. Notice the 
similarity?

This is *not* breaking new ground, Walter -- it's only going to break 
code. You can resolve that simply and easily with a minor adjustment.