Why Ruby?

[Nick Sabalausky]

"Andrei Alexandrescu" <SeeWebsiteForEmail at erdani.org> wrote in message 
news:ie341e$bru$1 at digitalmars.com...
> On 12/12/10 6:44 AM, Jacob Carlborg wrote:
> [snip]
>> Conclusion:
>>
>> D needs a better and nicer looking syntax for passing delegates to
>> functions.
>>
>> Suggestion:
>>
>> If a function takes a delegate as its last parameter allow the delegate
>> literal to be passed outside the parameter list, after the function
>> call, and allow to drop the semicolon. Also allow type inference of the
>> delegate parameters. Looking like this:
>>
>> foo(bar) {
>> // do something with bar
>> }
>>
>> If the function takes other arguments before the delegate I have two
>> suggestions, either just have two parameter lists, each in its own pair
>> of parentheses:
>>
>> foo(3, 'a')(bar) {
>> // do something with bar
>> }
>>
>> Or have two parameter lists in one pair of parentheses seperated by a
>> semicolon:
>>
>> foo(3, 'a' ; bar) {
>> // do something with bar
>> }
>>
>> I think that the syntax I've used in these examples has previously been
>> proposed.
>
> Yah, it's been discussed a couple of times in the past. Both Walter and 
> myself are favorable to finding a good, simple lowering that improves 
> syntax without adding burden to the person who learns the language.
>
> By the way, lowerings are great. Defining features as lowerings is a huge 
> win in language definition, ease of understanding, and correctness of 
> implementation. Features that have been implemented through lowering have 
> had very few bugs - e.g. scope() and the new operator overloading, which 
> was only a week's work.
>
> Getting back to finding a good lowering, consider:
>
> foreach (a, b ; c) stmt
>
> A Ruby syntactic equivalent that clarifies what belongs to the block and 
> what belongs to the invoker of the block is:
>
> c.each do |a, b|
>   stmt
> end
>
> So a and b are passed to the block and each is a method of c (or more 
> general, each is a function called taking c as an argument). Going now 
> back to D, we can imagine the following lowering:
>
> fun (a, b ; c) stmt
>
> =>
>
> fun(c, (a, b) { stmt })
>
> This could and should be generalized for more parameters, which I'm sure 
> is very useful:
>
> fun (a, b ; c, d) stmt
>
> =>
>
> fun(c, d, (a, b) { stmt })
>
> Of course "fun" could be actually "obj.method".
>
> With this we have a compelling syntax that has semantics obtained via 
> lowering.
>

I'm still concerned about this inconsistency:

void foo1()
{
    foreach(a, b; c) {
        return; // Return from foo1
    }
}

void foo2()
{
    fun(a, b; c) {
        return; // Effectively a "continue;" even though the syntax suggests 
otherwise.
    }
}

And one consequence of that is that contrary to what has been said, this 
would *not* allow foreach to be implemented as a library function.

I can appreciate the difficulty of getting the delegate's flow control to be 
handled as expected, but I think going ahead with this sugar without 
addressing that in some way would be a mistake.