Return-Path: Received: from SEGATE.SUNET.SE by xiron.pc.helsinki.fi with smtp (Linux Smail3.1.28.1 #1) id m0t8CV8-0000ZQC; Wed, 25 Oct 95 22:32 EET Message-Id: Received: from listmail.sunet.se by SEGATE.SUNET.SE (LSMTP for OpenVMS v1.0a) with SMTP id E14E406D ; Wed, 25 Oct 1995 21:32:42 +0100 Date: Wed, 25 Oct 1995 13:02:00 LCL Reply-To: BARRETO%VELAHF@ECCSA.TR.UNISYS.COM Sender: Lojban list From: Paulo Barreto Subject: Re: conflicts in grammar.235 X-To: lojban%cuvmb.cc.columbia.edu@TRSVR.UniGate1.Unisys.COM To: Veijo Vilva Content-Length: 1712 Lines: 36 me: >I checked grammar.235 with yacc and three shift-reduce errors were >reported. Mark: >I don't know that shift/reduce conflicts qualify as a "problem." >They're an ambiguity in the grammar, but yacc (and presumably lojban) >generates an unambiguous parse in these cases by resolving in favor of >shifting instead of reducing (I think). If a grammar submitted to yacc presents a conflict it is either ambiguous (most probably, in practice), or non-LALR(1). yacc solves conflicts by looking for explicit precedence/associativity clauses, favoring shifts (if the conflict is shift/reduce), or favoring the first production listed in the grammar (for reduce/reduce conflicts). If grammar.235 is simply non-LALR(1) but still unambiguous, some rewriting may be done to force that property (and a big headache :-) If it is AMBIGUOUS, the LANGUAGE (more precisely, the underlying context-free model of the language) will always admit more than one parse for some sentence, notwithstanding the yacc workaround to select one of them. I wouldn't expect every listener to behave exactly like yacc; hence misunderstanding may arise. Even worse: you have in general no warranty that the language accepted by the yacc parser is the same generated by the grammar. Perhaps in circumstances like building a parser this kind of grammar is adequate (giving rise to smaller parsing tables, etc.), but I really don't think that a language designed to be syntactically unambiguous should tolerate such an anomaly in its formal definition. Paulo S. L. M. Barreto -- Software Analyst -- Unisys Brazil Standard disclaimer applies ("I do not speak for Unisys", etc.) e'osai ko sarji la lojban.