[antlr-interest] StringTemplate approach applied to ANTLR?
Wigg, J D
wiggjd at lsbu.ac.uk
Fri Jan 5 09:23:56 PST 2007
I agree in principle with Jose's suggestion (though I think templates
are using a sledge hammer to crack a nut!).
My approach in CPP_parser was to sub-class my application code to keep
it separate from the parsing code. This is quite easy to do, though it
still requires function calls from the .g file via CPPParser.cpp etc.
which can be controlled by #if statements. It is quite easy then to
remove my application code from the parser .g file by deleting these
#if blocks to enable the parser to be used by someone else for
different purposes. Don't forget that most application code will be
buried *somewhere inside* their productions.
Anyone interested in doing this for other languages can look at my
ReadMe text. CPP_parser is coded in C++.
Message copied from antlr-interest Digest, Vol 26, Issue 9
Date: Fri, 5 Jan 2007 13:11:15 +0100
From: Jose San Leandro <jose.sanleandro at ventura24.es>
Subject: [antlr-interest] StringTemplate approach applied to ANTLR?
To: Undisclosed.Recipients: ;
Cc: antlr-interest at antlr.org
Message-ID: <200701051311.16250.jose.sanleandro at ventura24.es>
Content-Type: text/plain; charset="us-ascii"
One thing that could be cleaned up in ANTLR (in my opinion), is mixing
definition with custom parsing logic. I mean, in ANTLR you can write
execute whenever a rule, an alternative or a pattern matches the
logic can be used to direct the parser or to do anything else.
That makes the .g itself coupled with the language the custom code is
output of antlr.Tool.
There's no clean separation between the rules describing the grammar
custom parsing logic.
Also, it makes reusing grammars more difficult than it should. You
a grammar and modify it to suit your needs, but whenever the grammar
started from changes you need to apply the changes to your branched
Shouldn't be better to separate the ANTLR flow into two steps?
1) You provide a .g file and the desired language the parser will be
implemented in. ANTLR would then generate the lexer and/or parser in
target language, as it does currently.
2) From the .g file, ANTLR also generates an interface and an no-op
implementation declaring all the hooks the grammar accepts. The
would support an optional parameter allowing a different
I haven't thought too deep in this. I wouldn't like a Context object
forth, but the potential interests me: get a standard set of official
grammars ready-to-use with no source-level changes.
It makes ANTLR less coupled to Java as well.
This e-mail message may be confidential and is intended only for the use of the individual(s) to whom it is addressed. It may contain information which is or may be confidential, non-public or legally privileged. Please do not disseminate or distribute this message other than to its intended recipient without permission of the author. You should not copy it or use it for any purpose nor disclose its contents to any other person. If you have received this message in error, please notify me by email immediately and delete the original message and all copies in your computer systems.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the antlr-interest