[antlr-interest] translation of $x references in v3.0

Scott Stanchfield scott at javadude.com
Sun May 1 14:16:45 PDT 2005


First, I'd suggest you make parameters and return values hash tables (or
some other simple dictionary). Very easy to manage that way.

As for $, I think you should have them be represented by some prefixed or
suffixed name in the generated code, like __foo or something unlikely to
collide with user-defined names. That way, $x and x are really two different
names in the code.


For @ I'd much rather see something that's user configurable along the lines
of xml namespace prefixes. (Right now I'm using it for XML attributes)

What do I mean?

First, I'd like to see plugins that can scan and modify the action code.
These plugins could replace special template expressions when scanning the
code, and there could be more than one plugin active.

If there's only one plugin active (let's say xml processing), something like
@foo would just mean "the foo attribute of the current tag".

If there's more than one plugin active for other code generation fun, you
could assign prefixes in the grammar. For example, suppose we were doing an
xml parser that wanted to collect some stuff into a list while it's parsing.
We could have a "data structure" plugin that provides simple structure
support.

For example (very loose syntax here...)


01 options(plugins) {
02     @=com.javadude.antlr.xml
03     @data=com.javadude.antlr.data.structure
04 }
05 
06 ...
07 
08 something options {@xmlTag="some-thing";}
09   : 
10     (fee  { @data:add("fees", $fee); )*
11
12     ( fie @data:add("fies", $fie); )+
13 
14     fo
15
16     { doSomething(@id, $fo, @data:list("fee"), @data:list("fie"));
17   ;


To explain:

01: defines plugin prefixes
    Anything with "@" is delegated to a plugin based
    on these prefixes. "@" refs w/o a prefix use the
    "default" (line 02), others use the prefix mapping

08: ANTLR delegates the @xmlTag option to the default
    plugin for the grammar (com.javadude.antlr.xml)
    The plugin processes the option or returns an
    exception describing why it didn't like it

10: @data:add is translated by the
    com.javadude.antlr.data.structure plugin
    $fee picks up the last result from a fee rule call
    (The fee result is passed to @data:add)

17: @id is translated by the default plugin. In this
    example, the XML plugin says "@ in action code means
    get the attribute"


Overall, this is pretty simple, but we have to find the right hooks to add
in antlr for the plugins. I did some of this for the xml plugin, but it
isn't general enough yet. In the above example, we need at least:

public interface Plugin {
  void option(String name, String value);
  boolean canTranslateAction(String action);
  String translateAction(String action);
  void startRule(...);
  void endRule(...);
  // and perhaps some code generation hooks
}


[I know that some folks will say "you can just generate a tree and write a
tree parser for your custom actions instead of plugins". I know I can. I
don't want to. Not everything needs trees.

I've written several parsers at my last few jobs, mostly for simple
expression or XML parsing. Esp in the XML case, I don't want a tree b/c
it'll take up too much RAM (ala DOM). I want simple scan & process parsing.

If I'm writing a language translator or compiler, trees are very nice. For
expression and XML parsing, they can be overkill.]


That's my 10c, some of which I've already mentioned in earlier posts (but
this might be a little more coherent)

Later,
-- Scott




More information about the antlr-interest mailing list