Hi,

2010/4/8 Caleb Clausen <vikkous / gmail.com>:
> Yusuke Endoh wrote:
>> BTW, I also noticed that block call with `do' keyword does not work in
>> `until' condition:
>>
>> ?until begin 1.times { } ? ?end do end # ok
>> ?until begin 1.times do end end do end # parse error
>> ? ? ? ? ? ? ? ? ? ? ?~~
> [snip... more like that]
>>
>> This is because the underlined `do's are not considered as block call
>> but beginning of `until' body.
>>
>> Although this is confusing a little and can be actually fixed, the fix
>> needs many COND_PUSH(0)/COND_POP(), which may decrease performance and
>> code maintenability. ?In addition, writing such a long and complex
>> condition directly is absolutely bad (even insane) style.
>> So, we should accept the above behaviors as spec, I think.
>
> Wait.... please don't harden any bugs into the specification of the
> language. If you want to say that it's too obscure/too hard to fix,
> that's fine. WONTFIX is ok, under the circumstances. If you want to
> say it's implementation dependent behavior, that's at least
> acceptable. But let's not pretend that what's clearly a bug is
> intended behavior. (Best of all would be to fix the bug, but I'm not
> really asking for that.)

You are right.  I guess it be considered as WONTFIX.


> My own lexer & parser were able to parse all the examples in this bug
> report correctly and I did not need to change anything.

Great.


BTW, how about the following? :-)

# ok
while (((((((((((((((((((((((((((((((false)))))))))))))))))))))))))))))))
do; end

# parse error
while ((((((((((((((((((((((((((((((((false))))))))))))))))))))))))))))))))
do; end


If your CPU is 64 bit, please run after 32 '(' and ')' are added :-p


IMHO, do_cond (omittable `do' keyword in the part of while/until/for
constructs) brings confusion but little benefit to the Ruby syntax.
How about removal of do_cond in 2.0?

-- 
Yusuke ENDOH <mame / tsg.ne.jp>