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

[Terence Parr]

Reasonable thoughts. I'm adding a note.
Ter
On Jan 20, 2009, at 5:12 AM, Johannes Luber wrote:

>
>>> 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
>
> List: http://www.antlr.org/mailman/listinfo/antlr-interest
> Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-email-address