Re: coupling LALR with a scanner?

"Armel" <armelasselin@hotmail.com>
Fri, 16 Sep 2011 10:47:24 +0200

          From comp.compilers

Related articles
coupling LALR with a scanner? armelasselin@hotmail.com (Armel) (2011-07-05)
Re: coupling LALR with a scanner? armelasselin@hotmail.com (Armel) (2011-07-07)
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)
[3 later articles]
| List of all articles for this month |

From: "Armel" <armelasselin@hotmail.com>
Newsgroups: comp.compilers
Date: Fri, 16 Sep 2011 10:47:24 +0200
Organization: les newsgroups par Orange
References: 11-07-013 11-07-015 11-07-018 11-08-004 11-09-016
Keywords: parse
Posted-Date: 17 Sep 2011 15:17:57 EDT

>I don't understand why you want to have a different scanner for each
>state. The parser can easily make the decision, whether a token is
>valid. In fact, an LALR parser already has this information in the
>parser tables, so why make a simple situation complicated?


IELR was exactly made for that reason, as a first step to PSLR: some
grammars have no 'tokens' and 'grammar rules', they just have a 'grammar'
where mutually exclusive tokens are present, e.g. you cannot make a
Javascript single lexer as there are state where / (slash) means 'start of
regular expression' (of course the content of the regular expression follows
totally different lexing rules than the rest of the text) whereas in other
states it means 'division' operator. If your parser cannot tell which of the
two lexers to use, you are off.


> this could be confusing to the the user of your language.
people like Perl and Javascript, so we have to make parsers for those
languages :)


by the way I'd be open to use IELR, but I have to read the paper again
because it's far from being easy to understand and implement...


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



Post a followup to this message

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