[antlr-interest] Parse tree problem.

Bharath Sundararaman bharath at starthis.com
Wed Aug 4 14:16:09 PDT 2004


Hi all,

class TinyCParser extends Parser("ParseTreeDebugParser"); or
Parser("antlr.ParseTreeDebugParser"); or even Parser(ParseTreeDebugParser);
--> gives me an error saying "SEMICOLON expected after Parser". Anybody else
came across this problem? I use ANTLR 2.7.3, by the way and I am following
the tutorial on http://www.antlr.org about parse trees.

Thanks!

Bharath.

-----Original Message-----
From: Tiller, Michael (M.M.) [mailto:mtiller at ford.com] 
Sent: Wednesday, August 04, 2004 12:30 PM
To: antlr-interest at yahoogroups.com
Subject: RE: [antlr-interest] 3.0 multiple language support


I want to clarify one thing.  In the current ANTLR, there already is a
special action language for building trees.  I don't have a problem with
that and I'm not suggesting that *it* be moved into a macro and put in
another file.  My point is this...it is fine to have an action language that
does all the *common* things (e.g. building trees, skipping tokens, changing
token types, etc).  But by externalizing everything that is more complicated
(looping over symbols in a symbol table, working with specialized data
structures, etc) you gain several things:

1) Language independence - The action language should have a clear mapping
to all target languages.  That mapping should include, conceptually, the
ability to do basic things like call functions/methods in the target
languages.

2) Improved readability - Sure you want the ability to put simple things
right there in the rules and you would degrade readability if you moved
those kinds of things.  But when you move more complicated stuff out of the
grammar, I think that is a good thing.

3) Not inventing another general-purpose programming language.

Based on the response to this thread, it seems like different people would
approach this kind of thing in different ways.  So it seems like the best
solution is to be as flexible as possible.  I think a basic action language
could be used to handle most grammar related actions. For people who need to
support multiple languages I think the macro approach makes sense.  For
those who still want language specific actions in the grammar, I never
objected to having that as well.

--
Mike

> -----Original Message-----
> From: Sebastian Kaliszewski [mailto:sk at z.pl]
> Sent: Wednesday, August 04, 2004 11:56 AM
> To: antlr-interest at yahoogroups.com
> Subject: Re: [antlr-interest] 3.0 multiple language support
> 
> Thomas Dudziak wrote:
> >>I really don't like this. Actions (esp. predicates) are part of the
> grammar.
> >>Separating them makes code much harder to read, analyse and maitain,
as
> one
> >>has to jump around the code text.
> >>Macros might be a nice idea, but they should be intermixable with
the
> >>parser/lexer definition in the same file.
> >
> > I find Michaels solution much easier to maintain. Imagine the Java 
> > grammar with embedded actions for all supported languages - it will 
> > surely be not readable anymore.
> 
> I'm not seeing that as unreadable. But spreading code doing particular
> (simple) thing among many places in different files is. Besides it's 
> easy to filter actions in all but particular language out
(if
> syntax is clear, like: {c++: /* rule here */}). There could be even
such
> action filter tool acompanying ANTLR distribution.
> 
> 
> > Defining labels, e.g.
> > "process_some_rule" is far better IMO.
> 
> If someone needs to do some more complicated processing which is
logically
> separate one should put that processing into additional
function/procedure
> -- this is a prime good coding rule in all general purpose languages.
But
> for simple stuff this makes no sense. Simple stuff should be done
inline.
> And from my experience most of the in-grammar actions are such simple 
> stuff.
> 
> The separate actions proposition would for example enforce me to do 
> something like that:
> 
> NEW_LINE
>    : "\n" { process_new_line() }
> 
> And then in separate file:
> process_new_line()
> {
>    my_line_count++;
>    nextLine();
> }
> 
> 
> No, thanks... I vote strongly against such a nonsense.
> 
> 
> > You can simply add all
> > information as parameters that is required by the action. The net
result
> > is that the grammars themselves are target-language-independent
> 
> And in what percentage of uses we need that?
> 
> 
> > (remember the newbie asking about a Java version for the SQL grammar
?)
> 
> That newbie still needs actions for the grammar. And it's easier to
look
> at
> the code where (mostly simple one liners) actions are placed together
with
> production rules, not in separate files. Like this is one of the 
> advantages of most contemporary languages over C & C++ -- no stupid 
> separatre
headers
> to declare stuff which will be unrolled in another file.
> 
> 
> > and you have the action in a concise form, perhaps in a single
class. Or
> > Antlr generates abstract method declarations (for C++/C#/Java) in
the
> > parser that the developer has to override in a concrete parser
subclass
> > (template and hook).
> 
> Sorry, but one of the prime advantages of recursive descent parsing is 
> that actions can be precisely placed, and together with generated code
combined
> into whole methods.
> 
> 
> > There are a few situations where this might seem like overkill
> 
> This is overkill in vast majority of situations not just few!
> 
> 
> > (e.g.
> > maintaining and using a counter for a ()* subrule that shall be 
> > traversed like 20 times), but there might be better ways to handle
these
> > situations (e.g. defining syntax for it - say, ()[20] - and letting 
> > Antlr work out the details).
> 
> And have yet another uncompheresible language loaded with [*&%(|\`@#@$
and
> stuff, i.e. "executable line noise". No, thanks...
> 
> rgds
> --
> Sebastian Kaliszewski
> 
> 
> 
> 
> Yahoo! Groups Links
> 
> 
> 
> 



 
Yahoo! Groups Links



 




 
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