[antlr-interest] more specific (lang independent?) actions (WAS: header sections)
Terence Parr
parrt at cs.usfca.edu
Thu Nov 18 09:59:48 PST 2004
[yahoo groups suck...didn't see this come across either their web
interface or email...sending again...stupid yahoo]
Howdy. Along these lines, I'm feeling a general trend in my thoughts
towards having more formal actions rather than "type in whatever you
want and hope it compiles" actions.
For starters, this header issue. We only want the header so we can say
"put me in this package and import this stuff" and we need actions
within the parser (outside of a rule) to define constructors, methods,
define variables etc...
Actions within rules. For trees, we have suffix operators that work
great in many cases but we currently have to use random actions and
special #(...) expressions within those actions. Currently, we have to
"read" actions looking for those special operators. Happens in lexers
too. we have to look for $setType etc... The $setType is meant as a
language independent way to set the type. For the interpreter (as part
of the GUI) in ANTLR 3, I need to be able to see these set type and set
channel actions w/o having to read java, c#, c++, etc...
So, here's the start of an idea. Let's *say what we really mean*
instead of just providing a slot to put an action, hoping it will end
up in the right spot in the output. The 'header "section" {..}' thing
is the right direction, but let's make it more meaningful and identify
the things we need to be able to say:
* parser superclass if OO language
* package, module, namespace ...
* includes, imports etc...
* constructor OO or init() non-OO
* instance variables (or similar shared var in non-OO languages)
* instance method definitions needed by the parser that you want
directly in the output class
* lexer actions (set type, ...)
* tree construction actions
Anything else? Well, let's start with that and see if a syntax
appears. For now, I'll stay away from what is really inside the action
except for lexer/tree actions (separate thoughts there). (I'm making
the terms java-centric <snicker>).
grammar P(...options..., package=org.antlr.test, super=DBGParser);
import {
import java.io.*;
}
init {
code, not a ctor method def. Just code to init
antlr will generate this into the ctor or whatever
}
fields {
String currentMethodName;
int level;
}
methods {
public void computeFoo() {
...
}
}
start : ID '=' INT ^{start = ^('=' ID INT)} ;
ID : ('a'..'z')+ ;
INT : ('0'..'9')+ ;
WS : (' '|'\t')+ ${channel=99;} ;
where I have integrated the parser/lexer and used language indendent
actions for lexer and tree stuff (similar to Loring's I believe).
These are just initial thoughts that we should discuss; naturally,
we're just at the idea stage--don't take this as "what that maniac is
doing." ;)
Ter
--
CS Professor & Grad Director, University of San Francisco
Creator, ANTLR Parser Generator, http://www.antlr.org
Cofounder, http://www.jguru.com
Cofounder, http://www.knowspam.net enjoy email again!
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/antlr-interest/
<*> To unsubscribe from this group, send an email to:
antlr-interest-unsubscribe at yahoogroups.com
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
More information about the antlr-interest
mailing list