[antlr-interest] Parse tree problem.

Bharath Sundararaman bharath at starthis.com
Wed Aug 4 14:50:15 PDT 2004


Sorry Joan, it was a typo in my email. I did try "antlr.debug.." and I got
the same error.

Thanks for your reply, though.

Bharath.

-----Original Message-----
From: Joan Pujol [mailto:joanpujol at gmail.com] 
Sent: Wednesday, August 04, 2004 4:23 PM
To: antlr-interest at yahoogroups.com
Subject: Re: [antlr-interest] Parse tree problem.


Use this:
class ParserName extends Parser("antlr.debug.ParseTreeDebugParser");

You missed the debug word in the packet name.

Cheers,

On Wed, 4 Aug 2004 16:16:09 -0500, Bharath Sundararaman
<bharath at starthis.com> wrote:
> 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
> 
> 
> 
> 
> 


-- 
Joan Jesús Pujol Espinar


 
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