Message-Id: <199510251940.PAA16481@locke.ccil.org>
Date:         Wed, 25 Oct 1995 15:32: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

la dn. cusku di'e
> Shift/reduce conflicts tend not to be much of problem with yacc

Syntactical conflicts are not much of a problem for a human to parse
any natural language. The problem is that Lojban is claimed to be
syntactically unambiguous.

As a practical consideration for compiler construction, I agree
with you. Take for instance the well-known "dangling else" construct
present in many programming languages; it's easier to keep the
ambiguity and solve the conflicts a priori than to rewrite the grammar.

However, yacc's workarounds does not make a grammar less ambiguous.
Take an intrinsically ambiguous context-free language. Given a suitable
grammar, yacc will generate a parser for it. Still the grammar, as well
as the language, are syntactically ambiguous: parsers that were not
generated by yacc could parse sentences differently, as different
(and valid) parses do exist.

I read somewhere that some flaws in Loglan were detected and solved
with yacc. If we now keep new flaws, why were the original ones
removed at all? On the other hand, if the conflicts are due to
non-LALR(1) constructs (but still LR(k) for some k, say), then only
the usefulness of yacc is reduced as a check for unambiguity.

I think the best solution is to find out why the conflicts arise, and
rewrite the grammar to circumvent them. This does not mean changing
the language, only the grammar.

    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.