|
Boost-Build : |
From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-03-12 14:11:17
----- Original Message -----
From: "Christopher Seiwald" <seiwald_at_[hidden]>
To: <david.abrahams_at_[hidden]>; <jamboost_at_[hidden]>
Cc: <rmg_at_[hidden]>
Sent: Tuesday, March 12, 2002 1:55 PM
Subject: Re: [jamboost] Problems
> On yacc & OSF:
>
> | > I'm just looking at all the changes made to jamgram.yy in the
Perforce
> | > version. I can't see any left-to-right-recursion changes at all.
> |
> | Good point. Though the I thought Perforce people claimed to have
made
> | those changes, I think my brain is reminding me that left-recursion
is
> | better with bottom-up parsers like YACC, and that from the
comments...
> |
> | * right-recursive so rules execute in order.
> |
> | ...they don't know how to deal with left-recursive rules properly.
>
> Left recursion works better, in that it saves parser stack space. It
> can reduce "foolist : foolist foo" as soon as it sees "foo". If you
> use "foolist : foo foolist", it has to stack up "foolist" productions
> until it sees something other than "foo". Lots of foos: busted stack.
Yes, that fits with my notion of LALR.
> But if you don't stack it in the parser and you want L->R semantics,
> you have to stack it in the execution, or do an intermediate step of
> turning your chains around.
I dispute this. It seems to me the only thing you're buying is delayed
evaluation, which I don't think gives any advantages here.
Let's discuss what you mean by "L->R" semantics. I presume it means that
in, e.g., lists of rules, you evaluate the leftmost rules first:
rules : rule
{ evaluate($1); }
| rules rule
{ evaluate $(2); }
;
This evaluates all the rules in L->R order. What am I missing?
> Jam stacks it in the parser since it is a
> one-liner. Handling it in the execution or turning the chains around
> is less pleasing for the three needed cases (rules, cases, lol).
>
> | Oh, maybe I misunderstood the Perforce claim. OK, then I think we
should
> | be disabling YACC on OSF at least, and probably everywhere just to
be
> | safe.
>
> Put at the top of jamgram.yy "#define YYMAXDEPTH 10000" and you'll
have
> the same stack size as on modern yaccs. If someone generates a
Jamfile
> with more than 10k rules-in-a-block, cases-in-a-switch, or lol
argument
> list, we might have to revisit this approach.
Doesn't each level of nesting count here?
I have rules which include files, which define rules...
Anyway, 10000 sounds like a cheap and effective workaround.
Thanks,
Dave
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk