From: Caleb Clausen Date: 2005-10-13T14:33:08+09:00 Subject: Re: Default argument values for blocks 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.