From LOJBAN@CUVMB.BITNET Sat Mar 6 22:45:33 2010 Reply-To: "Carl D. Burke" Sender: Lojban list Date: Mon Dec 4 11:47:13 1995 From: "Carl D. Burke" Subject: Re: LR(k) Lojban Grammar To: LOJBAN%CUVMB.BITNET@cunyvm.cuny.edu Status: OR X-From-Space-Date: Mon Dec 4 11:47:13 1995 X-From-Space-Address: LOJBAN%CUVMB.BITNET@UBVM.CC.BUFFALO.EDU Message-ID: >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