Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!border4.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!news.iecc.com!nerds-end
From: "Armel" <armelasselin@hotmail.com>
Newsgroups: comp.compilers
Subject: Re: coupling LALR with a scanner?
Date: Tue, 20 Sep 2011 09:40:23 +0200
Organization: les newsgroups par Orange
Lines: 36
Sender: news@iecc.com
Approved: comp.compilers@iecc.com
Message-ID: <11-09-023@comp.compilers>
References: <11-07-013@comp.compilers> <11-07-015@comp.compilers> <11-07-018@comp.compilers> <11-08-004@comp.compilers> <11-09-016@comp.compilers> <11-09-017@comp.compilers> <11-09-022@comp.compilers>
NNTP-Posting-Host: news.iecc.com
X-Trace: gal.iecc.com 1316575164 75771 64.57.183.58 (21 Sep 2011 03:19:24 GMT)
X-Complaints-To: abuse@iecc.com
NNTP-Posting-Date: Wed, 21 Sep 2011 03:19:24 +0000 (UTC)
Keywords: parse
Posted-Date: 20 Sep 2011 23:19:23 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:273

"Paul B Mann"  a icrit dans le message de groupe de discussion :
>> IELR was exactly made for that reason, as a first step to PSLR: some
>IELR(1) does not solve this problem.  It solves the problem of reduce-
>reduce conflicts in an LR(0) [...]

OK I did not sentenced that right, this is PSLR which does all the
lexer/parser integration (hence Pseudo Scannerless LR).

>What you described with Javascript is a little language inside of
>another language.  Why not switch parsers when a slash ('/') is
>encountered if necessary?

The problem is that / is used as a normal token AND as the start for regular
expression.
For example these are two valid sequences:
var regexpr = / b + a /
                    2;
var numeric_var = 1 / b + a /
                    2;

The 2; on the following lines will have two different meanings, in case
'regexpr', it is an instruction setting the expression value (as used in
eval() ), in the case second case, 2 is the second operand to a / operator.

I insist a bit on this to show there is no 'right side' heuristic to
determine / b + a / is a regular expression. On the other hand the '1'
expression could be as complex as you can imagine.

Of course in the presence of something like expr / expr the parser knows the
/ is for a division, and if the / is found where expr is expected it knows
there is a regular expression coming.
I don't see how I could hack this into a scanner only. maybe some specific
preceding tokens. I have pass again some time on that question.

Armel