Re: %union foo bar baz and others { ... }

[Paul Eggert]

> From: Akim Demaille <address@hidden>
> Date: Sun, 02 Feb 2003 11:07:54 +0100
> 
> I should repeat that the dirty hack was only the closest code to what
> I think the code should do in the future: *post* parse the actions.

Hmm, I dunno, both the dirty hack and the current code are so far from
post-parsing the actions that I don't see why one is closer than the
other.  Both methods cause scan-gram.l to lexically analyze actions
differently depending on left context.  Both methods are quite distant
from any method that would lexically analyze {...} independent of context.

I agree with you that the code could be better compartmentalized.
Perhaps not so far that we actually have to scan actions twice,
though; perhaps we could just have scanner subroutines instead.  But
anyway, surgery like this can wait until after Bison 2.0 is out.

> I don't see why Bison should peek at the host language's escaping
> rules.  It needs to know where string/character/comment literal
> start and end.  The "meaning" of them is left to the compiler.

Bison needs to know the host language's escaping rules in order to
know where strings and comments end.  To repeat an old pun of mine:
the problem is inescapable.

>  Paul> I suspect that any attempt to go to the "future approach" that I
>  Paul> guessed at above will require many more changes to the parser and
>  Paul> lexer than the 20 to 30 lines at issue here.  The switch to the
>  Paul> "future approach" will be dozens or hundreds of times more
>  Paul> complicated.  I don't see why this current minor change would have
>  Paul> much effect on the feasibility of the big "future approach" change.
> 
> For instance, the BT parser should be introduced soon.  It will
> require something like %! { some code which is always executed, even
> when in non-deterministic exploration }.

"BT parser"?  What's that?  (Does "BT" mean BizTalk?  :-)  This must
be a post-2.0 issue, right?

If it's just an issue of flagging code that must always be executed,
then I see no advantage to the old approach.  For example, one could
easily use the syntax "%! {...}" for such code.  For the scanner, the
only thing you'd need to do is to add a new token "%!".  This would be
the same with both Bison 1.75 and Bison 1.875.  A simple solution like
that would work because the validity of the contents of {...} is not
affected by a preceding %!.

(As an aside, though, I'm a bit puzzled about the need for this
feature.  Is this one new to Bison, or has a feature like this
appeared elsewhere?  I don't see it in ANTLR, for example, and ANTLR
has supported backtracking parsers for ages.)

> Your approach requires another set of jumps and hoops,

Not if %! is as simple as what I'm guessing.