Message-Id: <199510251710.NAA11346@locke.ccil.org>
Date:         Wed, 25 Oct 1995 13:02:00 LCL
Reply-To: BARRETO%VELAHF@ECCSA.TR.UNISYS.COM
Sender: Lojban list <LOJBAN@CUVMB.BITNET>
From: Paulo Barreto <BARRETO%VELAHF@ECCSA.TR.UNISYS.COM>
Subject:      Re: conflicts in grammar.235
To: John Cowan <cowan@LOCKE.CCIL.ORG>
Status: OR

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.