Return to the
comp.compilers page.
Search the
comp.compilers archives again.
| Related articles |
|---|
| Intricate problem with scannerless LALR(1) parser mailings@jmksf.com (2008-06-06) |
| Re: Intricate problem with scannerless LALR(1) parser kamalpr@hp.com (kamal) (2008-06-08) |
| Re: Intricate problem with scannerless LALR(1) parser GeniusVczh@gmail.com (vczh) (2008-06-09) |
| Re: Intricate problem with scannerless LALR(1) parser paul@paulbmann.com (Paul B Mann) (2008-06-25) |
| Re: Intricate problem with scannerless LALR(1) parser gah@ugcs.caltech.edu (glen herrmannsfeldt) (2008-06-26) |
| Re: Intricate problem with scannerless LALR(1) parser paul@paulbmann.com (Paul B Mann) (2008-06-26) |
| Re: Intricate problem with scannerless LALR(1) parser parsersinc@earthlink.net (SLK Mail) (2008-06-27) |
| From: | SLK Mail <parsersinc@earthlink.net> |
| Newsgroups: | comp.compilers |
| Date: | Fri, 27 Jun 2008 21:47:41 -0400 |
| Organization: | Compilers Central |
| References: | 08-06-010 08-06-063 08-06-066 |
| Keywords: | parse |
| Posted-Date: | 28 Jun 2008 14:42:04 EDT |
The grammar itself as defined in the original note is trivially LL(1)
after the left recursion is removed. A quick yacc check would probably
say it is LALR(1) as well. Another reason that scanners and parsers
are kept separate is that the more powerful pushdown automata is not
needed for scanning. If you use a sledge hammer to crack a walnut, do
not be too surprised if you end up with squashed nut meat.
Return to the
comp.compilers page.
Search the
comp.compilers archives again.