From: Eric Mahurin <eric_mahurin@...>
Date: 2005-10-14T06:21:02+09:00
Subject: Re: Default argument values for blocks

--- Phil  Tomson <philtomson@gmail.com> wrote:

> 
> Eric Mahurin wrote:
> > --- Austin Ziegler <halostatue@gmail.com> wrote:
> >
> > > On 10/13/05, Phil  Tomson <philtomson@gmail.com> wrote:
> > > > While I tend to agree that there are probably much
> better
> > > parser
> > > > generators available now like ANTLR or even using a
> > > Ruby-based one like
> > > > Rockit, I can understand the hesitation to change from
> > > yacc.  It's a
> > > > huge amount of work for one, and there would need to be
> a
> > > lot of
> > > > testing to ensure that nothing has broke.  I suspect
> that a
> > > change from
> > > > yacc to another parser generator would delay Ruby2.0 by
> at
> > > least
> > > > several months.  Maybe that would be OK.  Perhaps there
> > > would be other
> > > > advantages gained by moving away from yacc that would
> help
> > > justify
> > > > doing so?
> > > >
> > > > I'm still in the "It might be a nice feature to have,
> but
> > > it's not
> > > > really needed enough to justify the kinds of changes
> being
> > > suggested"
> > > > category.
> > >
> > > I'm suggesting that it may be time for a parser change
> > > because the
> > > proposed language changes IMO are really really really
> ugly
> > > -- and I'd
> > > rather see:
> > >
> > >   foo = lambda { |foo = 1 | 2| puts foo }
> > >
> > > work than not.
> >
> > How do you interpret the above?
> >
> > foo = lambda { |foo = 1| (2|puts foo) }
> >
> > or
> >
> > foo = lambda { |foo = (1|2)| puts foo }
> >
> > I think the first interpretation is implementable in most
> > parsers (including yacc, I think) relatively easily if you
> just
> > don't allow "|" directly in the default value (unlike a
> normal
> > RHS).  The second interpretation would be more difficult
> > because it would require an arbitrary amount of lookahead.
> > Even if the parser can do it, I think arbitrary amounts of
> > lookahead should be avoided in a language because it will
> > result in a performance hit (like backtracking in regular
> > expressions).
> >
> >
> 
> I'm not a parser expert, but wouldn't the second example you
> pose be
> helped by the fact that you've enclosed the '1|2' expression
> in parens?
>  wouldn't that expression within the parens be evaluated
> first and the
> resulting value substituted into the 'foo = ' expression?

Notice the word "interpretation" in what I said.  Those were
the 2 interpretations for that example Austin gave above.



	
		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com