Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news.iecc.com!.POSTED!nerds-end From: Hans Aberg Newsgroups: comp.compilers Subject: Re: LR(1) Parsing : Error Handling & Recovery Date: Sun, 20 Jul 2014 01:38:56 +0200 Organization: A noiseless patient Spider Lines: 40 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <14-07-040@comp.compilers> References: <14-07-023@comp.compilers> <14-07-024@comp.compilers> <14-07-030@comp.compilers> <14-07-031@comp.compilers> <14-07-038@comp.compilers> <14-07-039@comp.compilers> NNTP-Posting-Host: news.iecc.com Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: miucha.iecc.com 1405818154 62072 2001:470:1f07:1126:0:676f:7373:6970 (20 Jul 2014 01:02:34 GMT) X-Complaints-To: abuse@iecc.com NNTP-Posting-Date: Sun, 20 Jul 2014 01:02:34 +0000 (UTC) Keywords: parse, LR(1) Posted-Date: 19 Jul 2014 21:02:34 EDT X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: csiph.com comp.compilers:1330 On 2014/07/19 23:40, Evangelos Drikos wrote: > On 7/19/14, 4:29 PM, Hans Aberg wrote: >> A GLR parser splits the parses in face of an ambiguity, which might be >> used instead. Bison supports this, but currently the actions during a >> parse split are not executed, and so cannot set context variables for >> the lexer, until the merge. > > A GLR parser splits on conflicts and thus needs two different types of > actions. As for Bison, there have been discussions to admit this, but as far as I know, it does not have it currently. > I recall that DParser uses the terms speculative and final. Or perhaps direct (immediate) and delayed, or something. Bison then only has the delayed. > In my GLR Builder I use the terms semantic checks & actions. > > Semantic checks are not delayed when the parser splits but they should > not have side effects. In general, it is unsafe to notify the scanner > that the parser has just reached a particular state. The lexer probably need some extensions as well. May be useful for parsing natural languages. > In contrast, you can query a symbol table to reject an active parser or > just create a node for the AST of the current parse. BTW, its my > impression that Elkhound and Elsa parse C++ with actions that actually > are immediate; but i have not read their code to be sure. It is possible to make a LALR(1) parser for C++: one parses a larger language, and cuts it down in the actions. > To conclude, in a deterministic LALR parser semantic actions are both > immediate and final but in a GLR parser this principle doesn't hold. Right. Only for simultaneous, parallel parses, if some reader here wonders.