[antlr-interest] Re: handling a common prefix
eric_mahurin at yahoo.com
Fri Jul 16 15:47:04 PDT 2004
Thanks, Monty. I looked at a few alternatives and just decided to
factor out as many of these attribute constructs out (moving them to
higher level rules where necessary) and also use syntactic predicates
where necessary. The main disadvantage to this approach is that these
attribute prefixes won't be direcctly associated with the following
structure in the AST - or at least I think, I haven't got that far.
--- In antlr-interest at yahoogroups.com, Monty Zukowski <monty at c...> wrote:
> Lexers can behave very much like parsers, some people put parser
> functionality into lexers for awkward languages like COBOL or FORTRAN.
> Also, see my article on parser filters.
> http://www.codetransform.com/filterexample.html That way uou could
> have a real parser working the token stream, but then package up the
> prefix constructs into a single token. Not quite what the example
> shows, but I'm sure you can get the general idea from it and figure it
> I'm heading for a long weekend so I won't be able to answer any more
> 'til Monday.
> ANTLR & Java Consultant -- http://www.codetransform.com
> ANSI C/GCC transformation toolkit --
> Embrace the Decay -- http://www.codetransform.com/EmbraceDecay.html
> On Jul 16, 2004, at 6:10 AM, thrutchy wrote:
> > I'm parsing verilog 2000 that allows almost every construct to be
> > optionally prefixed by something like this:
> > (* attribute = expression *)
> > Because it can appear in front of just about any construct and it has
> > an indeterminate number of tokens (due to expression), it is causing
> > ambiguities all over the place.
> > I think one possible solution would be to treat this whole thing as a
> > token by the lexer. I don't really like this solution because I will
> > eventually have to go parse what's inside.
> > Is there something else I can do? I want something in between a token
> > and a parser rule - psuedo token, where the rest of the parser treats
> > it as a token so that it can easily look ahead and resolve
> > ambiguities, but it can still be parsed into it's individual
> > components.
> > Eric
Yahoo! Groups Links
<*> To visit your group on the web, go to:
<*> To unsubscribe from this group, send an email to:
antlr-interest-unsubscribe at yahoogroups.com
<*> Your use of Yahoo! Groups is subject to:
More information about the antlr-interest