Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!news.glorb.com!news-out.readnews.com!news-xxxfer.readnews.com!news.misty.com!news.iecc.com!nerds-end From: "Armel" Newsgroups: comp.compilers Subject: Re: coupling LALR with a scanner? Date: Thu, 7 Jul 2011 10:28:46 +0200 Organization: les newsgroups par Orange Lines: 17 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <11-07-015@comp.compilers> References: <11-07-013@comp.compilers> NNTP-Posting-Host: news.iecc.com X-Trace: gal.iecc.com 1310060793 52665 64.57.183.58 (7 Jul 2011 17:46:33 GMT) X-Complaints-To: abuse@iecc.com NNTP-Posting-Date: Thu, 7 Jul 2011 17:46:33 +0000 (UTC) Keywords: parse, lex Posted-Date: 07 Jul 2011 13:46:33 EDT X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: x330-a1.tempe.blueboxinc.net comp.compilers:191 >[The usual approach is to set flex start states in your yacc or bison >parser. >-John] the LALR generator is one of mine and the idea here would be to select automatically the right lexer from the currently accepted tokens. I have the feeling that it must be doable. The target is to be able to write grammars with such dependencies naturally without any (user level) grammar actions and very minimal lexer meta-information (such as which lexer produces which tokens). Armel [I think you will find that users hate a compiler where in each state the lexer only recognizes the tokens valid in that state, since the only error message it could produce is "invalid token." Also remember that the LA in LALR stands for Look Ahead, and the lexer is often one token ahead of the parser. -John]