Why Ruby?

[Ary Borenszweig]

On 12/19/2010 03:45 PM, Andrei Alexandrescu wrote:
> On 12/19/10 11:31 AM, Ary Borenszweig wrote:
>> On 12/19/2010 02:28 PM, Andrei Alexandrescu wrote:
>>> On 12/19/10 11:21 AM, foobar wrote:
>>>> Andrei Alexandrescu Wrote:
>>>>
>>>>> On 12/19/10 5:08 AM, foobar wrote:
>>>>>> Walter Bright Wrote:
>>>>>>
>>>>>>> JRM wrote:
>>>>>>>> you could write:
>>>>>>>> sort!(@1>@2)(x);
>>>>>>> [...]
>>>>>>>> I think this idea (or something similar) is worth consideration.
>>>>>>>> It is
>>>>>>>> simply a small extension to an already existing feature that would
>>>>>>>> give D
>>>>>>>> a terser syntax for lambda's than most of the other languages
>>>>>>>> we've been
>>>>>>>> discussing.
>>>>>>>
>>>>>>> but:
>>>>>>>
>>>>>>> sort!("a>b")(x);
>>>>>>>
>>>>>>> is just as short! And it already works.
>>>>>>
>>>>>> I think that the issue here is not about syntax as much as it is
>>>>>> about semantics:
>>>>>> As others said, this is equivalent to dynamic language's eval() or
>>>>>> to D's string mixin and the this raises the question of hygiene
>>>>>> which sadly has no good solution in D.
>>>>>>
>>>>>> The main concern is this:
>>>>>> In what context are the symbols 'a' and 'b' evaluated?
>>>>>>
>>>>>> At the moment they cannot be correctly evaluated at the caller
>>>>>> context and do not allow:
>>>>>> sort!("a.foo()> b.bar()")(whatever);
>>>>>
>>>>> That does work. What doesn't work is calling nonmember functions
>>>>> looked
>>>>> up in the context of the caller.
>>>>>
>>>>> Andrei
>>>>
>>>> Either way, I personally don't care that much for another syntax for
>>>> delegates. I personally just want to see this ugly hack removed from
>>>> the standard library and discouraged. This feature promotes a code
>>>> smell. And for what, as you said yourself, to save 4 characters?
>>>
>>> "a > b" vs. (a, b) { return a > b; }
>>>
>>> Savings: 17 characters.
>>>
>>>> D should be consistent with only ONE delegate syntax. This is why Ruby
>>>> reads like poetry to its followers and c++ is like carving letters in
>>>> stone.
>>>
>>> Also, Ruby is well slower than C++ and other languages. It's easy to
>>> design a beautiful language if that's the primary concern. It's
>>> difficult to design a language when you want to keep in harmony a larger
>>> list of desiderata.
>>>
>>>> I much prefer that the lowering you mentioned to be implemented so
>>>> that performance wise this UGLY hack will have no benefits.
>>>
>>> The lowering will unfortunately solve little. I don't see how
>>>
>>> sort!"a > b"(array);
>>>
>>> is horrible but
>>>
>>> sort(a, b; array) { return a > b; }
>>>
>>> is beautiful and clear. Besides, that return is bizarre - did you mean
>>> return from the comparison or the caller? Ruby chose the latter, which I
>>> think is very sensible, but in that case you have a more difficult time
>>> returning locally.
>>
>> Not at all. The last executed statement is what gets returned. And that
>> doesn't only apply to blocks, but to normal functions:
>>
>> def foo
>> 1
>> end
>
> That would work if and only if it were designed into the language from
> day one - now it's too late. I encourage you to work out through various
> cases (if/else, switch, loops, returning void vs. a value) to see this
> will have considerable difficulties in D.
>
> Andrei

I was just pointing out that it works that way in Ruby, not that it 
should be implemented in D.