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

Johannes Luber jaluber at gmx.de
Sat Jan 31 09:20:38 PST 2009


Anthony W. Youngman schrieb:
> In message <673774B77DFB453C985A9D7053EC2FF7 at DFW5RB41>, Gary R. Van 
> Sickle <g.r.vansickle at att.net> writes
>>> 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).
> 
> Look at how Lilypond handles versioning (oh - and I think lily's parser 
> got rewritten in Antlr a while back - I'm not sure but I certainly see 
> the odd Antlr ref on the mailing list :-)
> 
> Each version of Lily knows what is the oldest version of the syntax it 
> supports, so if 2.12.2 sees "version 2.12.0" in an input file it's quite 
> happy. If it sees 2.11.59 it bails with "this input file is too old - 
> run convert-ly". I don't know what it would do if it saw 2.12.6.
> 
> But basically, it knows at what point there were incompatible syntax 
> changes, and objects if you try to feed it an old file. Okay, it might 
> (or might not) be a bit more work in Antlr deciding at what points to 
> break backwards compatibility, but it might also make life easier - keep 
> compatibility over several versions because you can, then break it and 
> Antlr knows to object about old input.
> 
> Cheers,
> Wol

I don't know lilypond but I doubt that this approach works for ANTLR.
ANTLR and ANTLR grammars consists of four parts: The tool, the runtime,
the grammar syntax, action code and the backend of the program, for
which the generated source is used. Of those the runtime, the action
code and the backend can't be simply converted automatically (though it
shouldn't be hard by hand).

Considering that those are very important parts, upon which the behavior
(and compileability) hinges, I believe that my approach is the best one
could do. Maybe with ANTLR/Yggdrasil things could work smoother, as the
action code won't be language dependent. But Loring hasn'T published
this spinoff yet.

Johannes


More information about the antlr-interest mailing list