[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LR(k) Lojban Grammar
>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