[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [updated PATCH] %language declaration

From: Paolo Bonzini
Subject: Re: [updated PATCH] %language declaration
Date: Thu, 07 Dec 2006 10:09:54 +0100
User-agent: Thunderbird (Macintosh/20061025)

1. Bison should never support a language with a different basic syntax than C/C++ since we don't want Bison to have to parse such a language in actions.

2. Bison might one day support such a language but Bison should parse actions for them horribly incorrectly. Thus, we'll refuse to have %language now to ensure that no one tries to parse them correctly then.

Obviously it's not #2. If it's #1, what's the harm in supporting %language now? That doesn't prevent us from opposing specific languages later.

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

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.

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.

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

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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]