Path: csiph.com!usenet.pasdenom.info!news.lightlink.com!news.iecc.com!.POSTED!nerds-end From: Robert Jacobson Newsgroups: comp.compilers Subject: Re: Grammar with low-precedence postfix operator? Date: Sat, 7 Feb 2015 10:30:43 -0800 (PST) Organization: Compilers Central Lines: 29 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <15-02-015@comp.compilers> References: <15-02-006@comp.compilers> <15-02-010@comp.compilers> NNTP-Posting-Host: news.iecc.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: miucha.iecc.com 1423385609 66990 2001:470:1f07:1126:0:676f:7373:6970 (8 Feb 2015 08:53:29 GMT) X-Complaints-To: abuse@iecc.com NNTP-Posting-Date: Sun, 8 Feb 2015 08:53:29 +0000 (UTC) Injection-Date: Sat, 07 Feb 2015 18:30:43 +0000 Keywords: parse, design Posted-Date: 08 Feb 2015 03:53:29 EST 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:1517 Thanks for the response. I'll have to digest this for a bit. On Friday, 6 February 2015 22:12:10 UTC-5, Kaz Kylheku wrote: > On 2015-02-05, Robert Jacobson wrote: > > I'm trying to write an ANTLR4 grammar for a language with a low precedence > > postfix operator (Wolfram Language with '&', but I use a simple toy grammar > > below). I'm struggling with finding the right pattern to express this > > language. > > I suspect this is not nicely solvable by LALR type tools. Only with hacks. But if I abandon implicit multiplication, collapse the grammar to a single rule, and let ANTLR handle operator precedence, ANTLR produces a parser that works. (I haven't made an attempt at a yacc grammar.) Perhaps this is because ANTLR produces ALL(*) parsers. > If you want 2+2++^3 to mean (2+2)++^3, that means that you need > a special low-precedence versions of ^ (and other operators) for that > case, so the ++ expression can be a constituent of something. > > Try something along these lines. This Yacc grammar only gives me one > shift-reduce conflicts, on account of the empty production rule for > pp_factor_continue. I didn't test it; I only skimmed through the state > transitions in y.output: I'll experiment with this, but this strategy strikes me as impractical for large grammars because you'd need to duplicate a significant portion of the grammar for the low-precedence versions of operators that can follow ++, yes?