From: David Heitzman <rubyinfo@...>
Date: 2011-08-25T13:29:05+09:00
Subject: Re: Possble bug in Ruby parser (Fixnum#times within "case" statement)

Yes, the parens let the parser know when the case statement ends.
If it sees the while statement, and then the case, I think when it hits 
the "end" it applies it to the while ?, and there the compilation fails. 
Oddly, it does work with the braces, a quirk I've personally experienced 
also.

My preference would be that  {..} === do .. end
in every case. if one fails, the other fails, and vice versa.

In this case, because you have while case ..
you would think it could handle the case statement first and then apply 
it against the while. But it's a lot to ask -- other languages have an 
enforced (..) after while, plus semicolons. Ruby doesn't complain much, 
but there are these edge cases where we see a little inconsistency. In 
my experience, after a few months using the language pretty often, I've 
stopped having trouble with these sorts of things for the most part.

another example, this works:

for y in (1..3) do
   puts 'y'
end

	but this fails:

for y in (1..3) {
   puts 'y'
}

????

Dave



On 08/24/2011 03:28 AM, Iñaki Baz Castillo wrote:
> 2011/8/24 Ruby Info<rubyinfo@aptifuge.com>:
>> Which suggests the parser is confused about which to evaluate first, the
>> while or the case block. But I don't think it's ambiguous, since the
>> case/when must be evaluated first, since the when only goes with the case.
>
> In that code it's clear that the "case" statement goes between ( ) so
> its "end" is the one before ")".
>
> So I see:
>
>    a)   while ( EXPRESSION )  ; end
>
> or:
>
>    b)   while ( EXPRESSION ) ; do CODE ; end
>
> both are valid. But in case EXPRESSION contains some "end" keyword and
> option a) is used, then ensure that EXPRESSION goes between ( ).
>