Return-Path: Received: from SEGATE.SUNET.SE by xiron.pc.helsinki.fi with smtp (Linux Smail3.1.28.1 #1) id m0tMa3m-0000ZUC; Mon, 4 Dec 95 14:31 EET Message-Id: Received: from listmail.sunet.se by SEGATE.SUNET.SE (LSMTP for OpenVMS v1.0a) with SMTP id 56223844 ; Mon, 4 Dec 1995 13:31:52 +0100 Date: Mon, 4 Dec 1995 07:27:00 LCL Reply-To: BARRETO%VELAHF@ECCSA.TR.UNISYS.COM Sender: Lojban list From: Paulo Barreto Subject: Re: LR(k) Lojban Grammar To: lojban%cuvmb.cc.columbia.edu@TRSVR.BITNET Content-Length: 2277 Lines: 49 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). I wish to point out en passant that there *is* at least one context- sensitive construct in Lojban, one that is strictly syntactical in nature: the ZOI quote, that requires the chosen opening delimiter to be identical to the closing one. This is of course dealt with very simply by the preparser. (.oisai I wish it wasn't necessary...) >[...] syntactic ambiguity exists, >it's just hidden by the mechanics of the parser. Not necessarily. The grammar may be LR(2); still yacc won't be able to handle it without resorting to a priori choices of parsing actions. There are two concepts of ambiguity. Grammar ambiguity occurs when a given grammar implies two derivations for some word of the language, though other grammars for the same language may allow only one derivation. Language ambiguity, on the other hand, is an intrinsic property of the language in that all grammars for it will be ambiguous as described above. >[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" :-) Of course, you could code in any kinds of "hacking", 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. co'o mi'e paulos. 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.