Re: Is this a some kind of regular grammar?

"Robert Thorpe" <robert.thorpe@antenova.com>
4 Jul 2002 23:18:05 -0400

          From comp.compilers

Related articles
Is this a some kind of regular grammar? daniel_shane_eicon@hotmail.com (Daniel Shane) (2002-06-28)
Is this a some kind of regular grammar? cfc@world.std.com (Chris F Clark) (2002-07-02)
Re: Is this a some kind of regular grammar? michaeldyck@shaw.ca (Michael Dyck) (2002-07-02)
Re: Is this a some kind of regular grammar? robert.thorpe@antenova.com (Robert Thorpe) (2002-07-04)
| List of all articles for this month |

From: "Robert Thorpe" <robert.thorpe@antenova.com>
Newsgroups: comp.compilers
Date: 4 Jul 2002 23:18:05 -0400
Organization: Antenova Ltd
References: 02-06-069
Keywords: parse
Posted-Date: 04 Jul 2002 23:18:05 EDT

> I have a question about a hypothetical grammar construction. The
> usual way of parsing involves the usage of a lexer combined with
> some type of parser that understands a grammar. One of the most
> common grammar type for the parser is LALR(1) because of its
> speed. There are also implementation of LL(k) but with high k's this
> can result in long processing time.


Only in some cases.




> One of my problems is that sometimes it is impossible for me to
> distinguish a token at the lexer stage, because multiple regular
> expression can match the same token depending on the context. What
> I need is an integrated solution which combines the lexer and the
> parser at the same time.


What you could do is just add stuff to the lexer to do the
recognition. For instance only have one regular expression match the
pattern and have some action code distingush between the two cases.
AFAIK C parsers sometimes have code in the lexer that distingushes
between typecasts and expressions in a similar way. This is a hack
but probably easier than resorting to exotic parsing methods for the
whole thing. If you designed the grammar redesign it to make your
life easier.


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.