Ok, this has been bugging me ever since the last time this issue came
up on redhanded.

I think that what we'd all like to see, ideally, is a default argument
syntax that looks like default arguments in def headers do. That is:

  proc {|a=expr| ... }

This creates an ambiguity if expr contains an |-operator. Which should
be resolved by requiring parentheses around the expression in that
case. This seemed like it ought to be pretty easy to implement.... so
I tried to see if I could get my RubyLexer to support the above
syntax. And, it took only about 15 minutes to code and test a tweak to
RubyLexer to make it all work right. (Actually, there's a small
problem with my tweak as currently written; it ought to be possible to
escape | with a dot as well as parentheses.... but that'd be even
easier to fix.)

(It may seem strange that I decided to address this in a _lexer_ since
it's really a _parsing_ problem. However, RubyLexer also has to be
half-a-parser, since it's a stand-alone lexer. Normally, lexers get
hints from their parsers about what the context is for the current
token; I wanted (perhaps foolishly, as it created a big pile of extra
work) to have RubyLexer work correctly in all cases even if there is
no parser. So, it is actually appropriate to hack RubyLexer to handle
this case.)

Flushed from my success with RubyLexer, I decided to see if I could
repeat it in ruby 1.9's yacc grammar. After some false starts, I
figured out that resolving the ambiguity meant throwing in a %prec
modifier for the right rule... and I found the rule in need of
hackery: any rule with |-as-goalpost should be very high precedence in
order to avoid the interpretation of |-as-operator.

But no matter how many different variations I tried, I could not get
ruby to build correctly again after tossing in a %prec (and modifying
the block argument list to accept default parameters). I don't
remember the details now... it might have been dieing merely because I
had made no effort to ensure that whatever comes after the parser is
able to understand the new syntax tree format that this change
necessitates. However, my now vague memory of this is that the error
seemed to be in the parser itself.

A little reflection should have shown me the futility.... Presumably
Matz and Nobu have tried all this already and been frustrated by the
same obstacle that I had been beating my brain bloody against. Why
should I, with my pathetic and measly yacc skills, expect to do any
better?

But... does anyone know why I couldn't get yacc to do what was so easy
in my hand-coded lexer? I've long since erased my yacc hacks in
disgust, but if anyone's interested enough to want to see them, they
can easily be reproduced.