[antlr-interest] adding "version" option to ANTLR grammars

[Johannes Luber]

> > From:  Johannes Luber
> > Another improvement would be to allow a comma-separated list. 
> > With it one can record all versions of ANTLR, with which the 
> > grammar works without any modifications.
> 
> The trouble with that is that it forces the user to predict the future.
> Maybe it will work with the next fifty versions, which may only have
> changes
> which don't affect the ultimate interpretation, such as bug fixes, speed
> improvements, and the like, but there's no way to specify that.  
> 
> The only way this sort of thing works is for the source file to declare
> "this is the standard I was written to".  It is then up to the
> interpreters,
> past, present, and future, to either modify their interpretation to match
> that of the specified standard (i.e. future ANTLR versions "degrading"
> their
> interpretation) or simply bail (e.g. ANTLR 3.1.2 tries to read a grammar
> that says its written to the ANTLR 8.5.6 standard, which it of course has
> no
> idea what that even is, so it can't possibly interpret it).
> 
> A halfway solution used by some (autoconf comes to mind) is to list a
> minimum required version of the interpreter.  It's a bit of a fine
> distinction, but this tends to be problematic in the opposite direction:
> it
> forces the developer of the interpreter (i.e. Terence et al) to never
> break
> backward compatability - i.e. always have one foot in the past.  It also
> doesn't actually tell anyone anything about the source; does
> "requires_ANTLR_version = 3.1.1" mean it's using the "^(" or the "#("
> rewrite syntax?  No way to know until you hit the first one, so why bother
> with the "requires" at all?

You misunderstand the intent. This option doesn't force ANTLR to behave in a particular way - it isn't built for supporting different modes and shouldn't be made this way. An example should makes this clearer:

A grammar is written for "3.2". Now one uses "3.2.1". ANTLR compares the strings and says: "Hey, the author did only use 3.2. Using me may cause problems. Proceed at your own peril." If everything works out, the user can add "3.2.1" to suppress the warning.

A few months later 3.3 comes out. Ter decided to scrap the current rewrite approach and to switch over ANTLR/Yggdrasil". The user switches to 3.3, tries to generate the source code, but receives a stream of error messages. And the message is:  "Hey, the author did only use 3.2 and 3.2.1. Using me may cause problems. Proceed at your own peril." Then the user knows that the cause is in the format switch (assuming he followed ANTLR's evolution), instead having to dig into the file.
> 
> > Once one does a 
> > backwards-incompatible upgrade (be it bugfix, changed ANTLR 
> > behaviour or the use of a new feature), the list is cleared. 
> 
> How do you do that once your grammar leaves your PC?  Your customer
> decides
> to upgrade his ANTLR install and now your program won't compile.

See above example, but basically you don't and the user is at least warned of the possibility of breakage.

Johannes
> 
> > And if someone is unsure if a grammar change makes things 
> > incompatible, he has to check merely the latest given version.
> > 
> 
> -- 
> Gary R. Van Sickle
> 
> 
> List: http://www.antlr.org/mailman/listinfo/antlr-interest
> Unsubscribe:
> http://www.antlr.org/mailman/options/antlr-interest/your-email-address

-- 
Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger