Message-Id: <m0tMe2M-0000ZUC@xiron.pc.helsinki.fi>
Date:         Mon, 4 Dec 1995 12:14:24 -0500
Reply-To:     "Carl D. Burke" <cburke@MITRE.ORG>
Sender:       Lojban list <LOJBAN@CUVMB.BITNET>
From:         "Carl D. Burke" <cburke@MITRE.ORG>
Subject:      Re: LR(k) Lojban Grammar
To:           Veijo Vilva <veion@XIRON.PC.HELSINKI.FI>
Content-Length: 1680
Lines: 40

>la karl. cusku di'e
>
>>[...] the last I remember was that the grammar
>>was not actually completely context-free -- there were some shift-reduc
>>conflicts that YACC resolved using precedence of rules/productions.
>
>Hmm, probably you read my posting about that. I posted an answer later
>(in Lojban): the problem was not in the grammar but in the yacc I was
>using (that mabla seldapma thing overflowed, and reported this by
>telling the grammar had conflicts).

OK -- I only caught part of that thread.  Most of the text in lojban
goes right into storage because I don't have time to work the translation :(

[portions snipped for length]

>>[Recursive descent is equivalent in power to any other context-free
>>parsing method, so that won't help and makes lack of ambiguity harder
>
>This is only true if you mean *backtracking* recursive descent. The
>usual meaning of "recursive descent" is that of an LL(1) parser, which
>is not quite "equivalent in power to any other context-free parsing
>method" :-)

Mea culpa; it's been 15 years since I had that class, and my head has
leaked a bit over time. :)  I guess my point was that it probably
wouldn't perform any better, requires more effort to build and maintain,
and makes verification more difficult.

>Of course, you could code in any kinds of "hacking",
.OI.UINAI.
> thus making your
>parser a full-powered Turing machine. This would also reduce my degree
>of confidence in the parser to a negative value :-) It's a relief
>that the yacc workarounds are *not* used, and that the definition of
>Lojban is *not* made in terms of a particular program.

I'm relieved to hear that too; now I can go back to lurking :)

co'o