Re: [updated PATCH] %language declaration

[Joel E. Denny]

On Thu, 7 Dec 2006, Paolo Bonzini wrote:

> It's neither #1 nor #2.  It's more like "People might one day want Bison to
> support a language with a different basic syntax than C/C++, and this might
> require massive changes to the parser, making it close to unmaintainable.
> Thus, we'll refuse to have %language now to set a precedent that Bison's
> operation must be as language-independent as possible (as opposed to the m4
> skeletons)."

Ok, but isn't that like building a little picket fence to stop an army?  
If these rogue developers are willing to try to make such massive changes, 
I doubt that the need to implement a simple %language or even a %perl is 
going to frustrate them enough to make them give up.  I doubt such people 
will notice the intended precedent unless we explain it... and we can 
explain it even with a %language already in place.

> I agree that this doesn't prevent us from opposing specific languages later.
> Also, Java also sets a (IMHO good) precedent of how to make changes to Bison
> for the sake of supporting more languages: no change to the parser, limited
> modifications to make the m4 skeletons more generic, but *no change* to the
> grammar parser.

However, Java has a very similar basic syntax to C/C++.  In fact, I wonder 
if there are any significant differences for our purposes.  I don't know 
Java well enough to be sure.

> > Then again, if we're not willing to parse any other syntax, I guess that
> > means we won't be adding very many other languages.
> 
> Actually, I think we can parse a lot of languages with some limitations. in
> their use.  Perl definitely has problems because of hieroglyphics in the name
> -- this might extend to PHP in the future if we support $foo. Python has some
> because of the indentation.
> 
> OTOH, Lisp has different semantics for apostrophes but you can restrict
> yourself to (quote a b c) instead of '(a b c).  Likewise Ruby and PHP
> interpolate variables within a quoted string, and in this case Bison may parse
> "the first token is $1" incorrectly.  But even with these limitations, the
> parser could "just work" for a lot of languages.

This all seems like risky business to me, and it could be very frustrating 
and misleading for the user.  I think it would be more reasonable to 
provide an alternate language-independent action syntax such that Bison 
has no need to balance braces and quotes.  Then we would provide escape 
notations in case Bison's special characters need to occur in the 
language.  To use Perl as an example:

  lhs: rhs
    ${
      my $$var = "text";
      $$var =~ m/(ex)/;
      print "These must be escaped: $$1 ", '$$}', "\n";
    $}

And the output is:

  These must be escaped: tt $}

I didn't give too much thought to the above, so it's probably not the best 
syntax, but hopefully you get the idea.  Just think of embedding Bourne 
shell in Makefiles, scripts in XML and XHTML, C inside m4, etc.  Sure, the 
resulting code is a bit ugly, so the Perl user would probably want to tuck 
large passages of code away in a .pm somewhere.  However, the behavior is 
predictable without the user having to worry about the differences between 
C and Perl syntax.

> (Note that I'm not endorsing in any way the creation of Bison skeletons for
> these languages...) ;-)

Me neither, and I don't mean to say we should work out a 
language-independent action syntax now.  I just mean to say that something 
like the above is the right way to avoid language-dependent parsing and 
yet still support other languages where the syntax is not otherwise 
compatible with the C/C++ parsing that Bison currently does.

> > Sorry to force you to play devil's advocate, but I feel like I'm missing the
> > point.
> 
> No problem, it can work well.  I hope this is clearer now?

Getting there.  :)