Why Ruby?

[Nick Sabalausky]

"Nick Sabalausky" <a at a.a> wrote in message 
news:ieji3n$10ou$1 at digitalmars.com...
> "Walter Bright" <newshound2 at digitalmars.com> wrote in message 
> news:iejejo$pfr$1 at digitalmars.com...
>> Nick Sabalausky wrote:
>>> Any problem with the other Scala/C#-style one?:
>>>
>>> (x, y) =>  x * y
>>>
>>> // Lowered to:
>>>
>>> (x, y) { return x * y; }
>>>
>>> (Maybe that was rejected before due the the weird float operators that 
>>> are now being ditched?)
>>
>> The problem with the (x,y) parameter lists, where x and y are the 
>> parameters, is that it is ambiguous with the existing syntax of (x,y) 
>> where x and y are types and the parameters are omitted.
>>
>> For example:
>>
>> void foo(int);
>
> But we already have:
>
>    (x, y) { return x * y; }
>
> So either there aren't any problems with it after all, or D's existing 
> delegate syntax is already broken.
>
> To be clear, with what I'm trying to suggest, the *only* thing that would 
> be different from the current delegate literal syntax is that part *after* 
> the parameter list. Ie:
>
>    PARAM_LIST_HERE { return x * y; }
>    // -->
>    PARAM_LIST_HERE => x * y
>
> Or if there's a problem with =>, then ->, or -->, or ::>, or :>, or 
> whatever. I'm not suggesting the param list be different in any way 
> fromhow t is now. (Although proposals from other people might differ.)
>

Slight correction: There is *one* other difference from the current delegate 
literal syntax: The part after => must be an expression rather than a 
statement or a block.

But again, I'm not suggesting any change to param list - except *maybe* to 
make the param's parens omittable for zero-param or one-param delegates, but 
*only* if there isn't a problem with that. I'm ok with keeping them if they 
really still need to be there in those cases.