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

[Akim Demaille]

 >> 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.

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

Yes, but one has some impact on the legibility of the code.  One was
there first, and I no see reason for another scheme, that you describe
as equally complex, to supersede it.

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

Which, apparently, is not for soon :(


 >> 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.

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

I don't think it will need that that soon.



 >> 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 }.

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

I don't know, it depends when 2.0 is out.  It refers to Backtracking.


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

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

I don't know how ANTLR makes the difference between delayed code, and
immediately executed code, that allows the implementation of something
like a "cut" to prune the wrong parses.



The current code is complex, and endangers the possibilities of
extending Bison in new ways.  It only asks for the users some more
discipline when writing a grammar, which is a good thing.  The
SC_AFTER_IDENTIFIER pieces of code is additional code, additional
burden, that should be removed from Bison.