Why Ruby?

[Nick Sabalausky]

"Jacob Carlborg" <doob at me.com> wrote in message 
news:ie5n2o$2v7s$2 at digitalmars.com...
> On 2010-12-12 19:27, Nick Sabalausky wrote:
>>
>> There's one important difference you missed. Granted, it's not applicable 
>> in
>> that particular example, but more generally, it's important:
>>
>> int foo()
>> {
>>      foreach (person ; account.people)
>>      {
>>          writeln(person.name);
>>          if(blah)
>>              return 7; // Returns from foo
>>      }
>> }
>>
>>
>> int bar()
>> {
>>      account.people.each((Person person) {
>>          writeln(person.name);
>>          if(blah)
>>              return 7; // Only tries to return from the delegate
>>      });
>> }
>>
>> In D, there is currently no way to convert "foo()" above to use a delgate
>> (at least not without odd contorsions). So if we were to make syntax 
>> sugar
>> for "bar()", it would get really confusing:
>>
>> int bar2()
>> {
>>      account.people.each(Person person)
>>      {
>>          writeln(person.name);
>>          if(blah)
>>              return 7; // Only returns from the delegate, not bar2!! 
>> WTF?!
>>      }
>> }
>>
>> There are similar issues with break, continue, and probably goto.
>>
>> In Ruby, the syntax sugar works out fine because you can make it work it
>> either way. You can create something that behaves like a delegate 
>> ("return"
>> only returns from the delegate), or you can create something that is 
>> treated
>> as part of the function it's declared within ("return" unwinds the stack 
>> and
>> returns from the function that created it). (Although Ruby leaves the 
>> choice
>> up the the caller. I'm not entirely convinced that's the right way to do
>> it.)
>>
>> D would need something similar for "passing a delegate" sugar to work out
>> sensibly. One idea is to say that if-and-only-if the "sugar" is used, 
>> it's
>> considered part of the original function that declared it rather than 
>> being
>> a true degelate. The function that takes the "sugared delegate" must 
>> declare
>> that it takes a "sugared delegate" instead of a normal one so that it can
>> make sure not to do this:
>>
>> doSomething();
>> callSugaredDelegateThatMightUnwindTheStackEvenWithoutThrowing();
>> doCleanup();
>
> Yes, absolutely correct, I totally forgot about this. D would need a way 
> to return from the delegate and a way to return from the context where the 
> delegate is called. Perhaps introduce a new keyword "yield"?
>

I've been reminded in another branch of this thread that foreach/opApply 
already handles this issue, so that approach could probably just be copied. 
Ie with:

foreach(item; somethingWithOpApply)
{
    if(item.isItBoyant())
        return item;
}

The body gets converted to a delegate which gets passed to opApply, but the 
"return" still works as expected. I would be interested to hear how exactly 
that works though, particularly when returning something other than void.