Why Ruby?

Jacob Carlborg doob at me.com
Sun Dec 19 08:06:07 PST 2010


On 2010-12-19 16:14, Andrei Alexandrescu wrote:
> 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 }

I never proposed that exact syntax, I don't think anyone else did 
either. I think just one person mentioned "->". This is the syntax I've 
proposed:

foo(3 * 4); // lazy argument/delegate
foo(a => a * 3);
foo(a, b => a * b); // or if not possible:
foo((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.

No, you also added the {} 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?

Nothing, but there are a lot of things you can say the same about. I've 
also got the impression that you are pushing for a more functional 
approach of coding and for that a short, good and working lambda syntax 
is necessary.

> 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?

If this isn't a very quick implementation this would low on the priority 
list. I would like to have the lambda lowering as well :)

>> 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

That syntax is just ugly.

-- 
/Jacob Carlborg


More information about the Digitalmars-d mailing list