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.)

My own lexer & parser were able to parse all the examples in this bug
report correctly and I did not need to change anything. I don't recall
any special or difficult code needed to make that possible. If you're
going to declare the above parse errors to be in the spec, then I
should go and try to emulate this bug in my own code. I'd really
rather not do that.

While humans would be unlikely to write any of the until loops you
gave as examples, a code generator might well do so. So it is not
entirely impossible that such constructions could be encountered in
the wild.


<grumble> redmine seems not to be accepting updates right now.