Why Ruby?

[Andrei Alexandrescu]

On 12/19/10 5:01 AM, Simen kjaeraas wrote:
> Walter Bright <newshound2 at digitalmars.com> wrote:
>
>> Simen kjaeraas wrote:
>>> The problem of D's lambda syntax is it is optimized for longer
>>> functions. Usually, the delegates I write are one line long. I cannot
>>> see that this syntax collides with anything at the moment, but feel free
>>> to enlighten me:
>>> { => 4; }
>>> { a => 2*a; }
>>> { a, b => a>b; }
>>> { => @ + @; } // turns into { a, b => a + b; }
>>>
>>
>> If size and simplicity of typing are critical, are those really better
>> than:
>>
>> "a>b"
>>
>> ?
>
> No. But often, you want to call a function in a lambda, in which case
> the string version croaks.

I'm not sure about the "often" part. For me, string lambdas do often 
suffice. When it doesn't, I use a lambda. D's syntax for lambdas is not 
syntactically heavy at all:

(a, b) { return a + b; }

The proposed alternative gravitates around

(a, b) -> { a + b }

So this discussion concerns a niche between short lambdas that can be 
expressed as strings and lambdas for which the actual word "return" is 
too much to type. In fact we're looking at the difference between 
"return " + ";" and " -> ". Four characters.

If the new syntax would be executed to perfection, to what extent would 
that improve your use of D? To what extent would it make the language 
more powerful? To what extent does it allow to do things you otherwise 
wouldn't be able to?

Equally importantly, where is this four-characters saver on the radar 
compared to fixing const's issues, discussing tail const, completing and 
then improving 64-bit support, fixing important bugs, or even adding the 
lambda lowering that was discussed earlier in this thread to be promptly 
forgotten?

> Also, it is not always possible to pass the
> lambda by template alias parameter, in which case the string version is
> right out the window.

unaryFunc!"a + b"

> As for functions taking a delegate, the {=>@+@;} syntax will not work
> with overloading or template functions (nor will the other syntaxen that
> elides types). It could also be that functions taking delegates are or
> should be rare, and thus not worth optimizing for.

I have no idea what {=>@+@;} does - it looks like a wrong paste from an 
early dialect of Perl to me. I have difficulty picturing someone who 
finds "a+b" or q{a+b} ugly but some other syntaxes discussed here palatable.


Andrei