Re: coupling LALR with a scanner?

"Armel" <armelasselin@hotmail.com>
Mon, 19 Sep 2011 13:52:06 +0200

          From comp.compilers

Related articles
[2 earlier articles]
coupling LALR with a scanner? uu3kw29sb7@snkmail.com (Karsten Nyblad) (2011-07-07)
Re: coupling LALR with a scanner? uu3kw29sb7@snkmail.com (Karsten Nyblad) (2011-07-08)
Re: coupling LALR with a scanner? armelasselin@hotmail.com (Armel) (2011-08-04)
Re: coupling LALR with a scanner? paul@paulbmann.com (Paul B Mann) (2011-09-13)
Re: coupling LALR with a scanner? armelasselin@hotmail.com (Armel) (2011-09-16)
Re: coupling LALR with a scanner? paul@paulbmann.com (Paul B Mann) (2011-09-17)
Re: coupling LALR with a scanner? armelasselin@hotmail.com (Armel) (2011-09-19)
Re: coupling LALR with a scanner? paul@paulbmann.com (Paul B Mann) (2011-09-19)
Re: coupling LALR with a scanner? armelasselin@hotmail.com (Armel) (2011-09-20)
Re: coupling LALR with a scanner? cdodd@acm.org (Chris Dodd) (2011-09-23)
Re: coupling LALR with a scanner? cfc@shell01.TheWorld.com (Chris F Clark) (2011-09-29)
Re: coupling LALR with a scanner? armelasselin@hotmail.com (Armel) (2011-10-02)
Re: coupling LALR with a scanner? cfc@shell01.TheWorld.com (Chris F Clark) (2011-10-03)
[1 later articles]
| List of all articles for this month |
From: "Armel" <armelasselin@hotmail.com>
Newsgroups: comp.compilers
Date: Mon, 19 Sep 2011 13:52:06 +0200
Organization: les newsgroups par Orange
References: 11-07-013 11-07-015 11-07-018 11-08-004 11-09-016 11-09-017
Keywords: parse
Posted-Date: 19 Sep 2011 15:28:30 EDT

>[This seems like an awfully complicated way to reinvent scanner start
>states. -John]


In Fact, This Is The Same. there is a big difference in usage with start
states guided through Bison/Yacc explicit actions: the scanner knows by
itself which start state to use AND can tell you up front that what you
expect to do is impossible. when two mutually exclusive tokens happen in the
same parser state e.g.


A => expr "/" expr
              | expr REGEXPR expr // imagining its possible in your language


B => expr "/" expr
expr => number | REGEXPR


REGEXPR = /[^/]*/


In case A the parser generator would issue by itself an error, in case B, it
would set automatically the lexer start states appropriately.
In both case it has a tremendous advantage: any developer can enter the
grammar, compile and have something working (or know why it won't work),
s/he does not need any more to be a scanner/parser guru.


By the way, nothing prevents start states with exclusive tokens from
being stuffed with all the other non-problematic tokens, so as to give
meaningful messages when an unexpected token happens.


Regards
Armel



Post a followup to this message

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