Re: Default argument values for blocks


Eric Mahurin wrote:
> --- Austin Ziegler <halostatue@xxxxxxxxx> wrote:
>
> > On 10/13/05, Phil Tomson <philtomson@xxxxxxxxx> 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?

I ask because a lot of people have suggested that requiring enclosing
bitwise OR expressions in parens in the block param would solve the
problem.

I don't see any way to do the following without lookahead:

foo = lambda { |foo = 1|2|3| puts foo }

And as you say the more lookahead you're doing, the slower the parser
will be.

The goalposts are problematic for this sort of thing. What about an
alternative (some have been suggested):

lambda{ (foo = 1|2) puts foo }

If that one is problematic, then maybe:
lambda{ |(foo = 1|2, bar = foo|3)| puts foo, bar }

This one was proposed long ago as a way to declare a var whose scope is
outside the block:
lambda { <foo = 1|2> puts foo }


But again, I think we should hold out for the 'ideal' syntax or just
forget about the proposed feature.

Phil

.

Relevant Pages

  • Re: Redrawing issue
    ... I think you guys are right in suggesting to start the parser in a new ... The messagebox get stuck to the screen and does ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Parsing Expression Grammar
    ... The context *will be* unique at that point if the grammar is LL. ... many parser generators (including I must ruefully admit ... lookahead has been read to see if the token read is a token2. ... the parse continues with the predicate ...
    (comp.compilers)
  • Re: Writing a Boolean Statement Parser/Engine - Need help
    ... A user could enter a properly formatted boolean search string that I ... could pass to the parser. ... The engine would look at the values I returned against the initial ... The expressions use a syntax nearly compatible to VB and the evaluator ...
    (microsoft.public.vb.general.discussion)
  • Re: boolean logic parser - need help
    ... I'm looking to evaluate basic boolean expressions like: ... My old parser can evaluate Expression1 and/or Expression2. ... stored in an associative array or literals. ... It would be nice to have a real parser - YACC looks powerful but it ...
    (comp.programming)
  • Re: softwire for basm?
    ... a parser on top of it, allowing for expressions like you're ... but 'simply' and 'parser' in the same sentence do not usually turn out so simple in the end;) ... fld dword ptr ...
    (borland.public.delphi.language.basm)