On 7/12/10, Robert Klemme <shortcutter / googlemail.com> wrote:
> 2010/7/11 Caleb Clausen <vikkous / gmail.com>:
>> And it will make the parser a little bit more complicated; however,
>> there are already many special cases and complications in the parser.
>> One more is not a big deal. The philosophy of ruby's syntax overall is
>> to make the parser complicated if it makes life easier for the user. I
>> think this change at least ought to be considered under that
>> criterion.
>>
>> Now if you want to argue that Jan's proposal is esthetically
>> unpleasing, I won't really disagree. But just leave it at that. I hate
>> it when people try to throw up a lot of rhetorical chaff when their
>> real, and only valid, objection amounts to a subjective judgment call.
>
> It's not only that.  I question the balance of effort and benefit.
> Since most code around does not use the new syntax, you will have to
> support the old syntax as well.  As long as it is not mandatory only

Well, it has to be optional for another reason too: it would be far to
annoying to have to type 'end if' instead of 'end' at the end of every
if statement. I for one wouldn't be willing to sacrifice ruby's
celebrated terseness in this area just to make Jan happy.

> people benefit that use it.  OTOH, there is additional effort for
> backporting new code to projects that only use an old Ruby
> interpreter.  Given that we do not have this feature today and most
> people seem to be able to write code that gets the nesting right I
> wonder what the real benefit of this is given that there will be
> development effort for the interpreter, test cases, documentation etc.
>
> Uglyness was really just a side aspect although I agree I should have
> made this more clear.  Somehow I must have assumed that the other
> points are obvious. :-)

> I mostly agree apart from the missing aspect of efforts.  Even such a
> small change can cause significant other work to be done.

Ok, now this is a valid point, and one I tend to forget about.
Complicating code makes related work products more complicated but as
a single-minded engineer I only think about the code.

Additionally, I now see that there are some ambiguities around the
keyword 'do' which would have to be worked through before my proposal
could be implemented. So for example, this is valid currently:

  something begin
     42
  end do
     foo
  end

But with the proposed new syntax, the 'end do' would be interpreted as
an attempt to end a do block.  I'm not sure what, if anything, can be
done about this, or if it's just an issue that can be ignored.