[antlr-interest] StringTemplate approach applied to ANTLR?

[Wigg, J D]

Hello,
 
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++.
 
David Wigg.
 
Message copied from antlr-interest Digest, Vol 26, Issue 9
 
Message: 1
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"

Hi,

One thing that could be cleaned up in ANTLR (in my opinion), is mixing
grammar
definition with custom parsing logic. I mean, in ANTLR you can write
code to
execute whenever a rule, an alternative or a pattern matches the
input. Such
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
and the
output of antlr.Tool.
There's no clean separation between the rules describing the grammar
and the
custom parsing logic.
Also, it makes reusing grammars more difficult than it should. You
start from
a grammar and modify it to suit your needs, but whenever the grammar
you
started from changes you need to apply the changes to your branched
grammar.

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
the
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
generated API
would support an optional parameter allowing a different
implementation of
the interface.

I haven't thought too deep in this. I wouldn't like a Context object
back and
forth, but the potential interests me: get a standard set of official
ANTLR
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...
URL: http://www.antlr.org/pipermail/antlr-interest/attachments/20070105/03003aa1/attachment.html