[antlr-interest] Re: more specific (lang independent?) actions (WAS: header sections)

[Terence Parr]

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

On Nov 18, 2004, at 6:56 AM, Sebastian Kaliszewski wrote:
> Ric Klaren wrote:
>> [snip]
>> Since noone ran into this before
>
> I did. Had to do stupid #ifdefs to work around the feature. It's not a
> biggie, not a bug just a feature.
>
>> I guess it's just as good to mark it
>> in the docs.
>
> Wellyes, it should be at least documented.
>
>> [snip]
>> It's definitely something that should be done right in antlr3.
>
> Yup.
>
> rgds
> -- 
> Sebastian Kaliszewski
--
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/