Re: conflicts in grammar.235

[Paulo Barreto <BARRETO%VELAHF@ECCSA.TR.UNISYS.COM>]

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.