From jjllambias@hotmail.com Wed Dec 04 04:55:37 2002 Return-Path: X-Sender: jjllambias@hotmail.com X-Apparently-To: lojban@yahoogroups.com Received: (EGP: mail-8_2_3_0); 4 Dec 2002 12:55:37 -0000 Received: (qmail 15956 invoked from network); 4 Dec 2002 12:55:36 -0000 Received: from unknown (66.218.66.218) by m10.grp.scd.yahoo.com with QMQP; 4 Dec 2002 12:55:36 -0000 Received: from unknown (HELO hotmail.com) (216.33.241.173) by mta3.grp.scd.yahoo.com with SMTP; 4 Dec 2002 12:55:36 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 4 Dec 2002 04:55:36 -0800 Received: from 200.49.74.2 by lw8fd.law8.hotmail.msn.com with HTTP; Wed, 04 Dec 2002 12:55:36 GMT To: lojban@yahoogroups.com Bcc: Subject: Re: [lojban] Re: ka'enai (was: Re: A question on the new baseline policy) Date: Wed, 04 Dec 2002 12:55:36 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 04 Dec 2002 12:55:36.0845 (UTC) FILETIME=[70B943D0:01C29B94] From: "Jorge Llambias" X-Originating-IP: [200.49.74.2] X-Yahoo-Group-Post: member; u=6071566 X-Yahoo-Profile: jjllambias2000 la djorden cusku di'e >I think the first part is an overexaggeration of how difficult it >is to learn where NAI is allowed. It may not be very difficult, but it is an unnecessary complication. An arbitrary restriction. There is no justification for where it is allowed other than "that's how it is". >Yes, it simplifies the grammar (in terms of reducing the size and >number of rules), but is not a good idea because it's sloppy ("We >can't exactly decide when we want to allow -nai, so lets allow it >anywhere and decide what it means later")---giving up a piece of >rigorousness from the grammar. I don't see the point of rigour for the sake of rigour. Why are we not as rigorous with the rest of UI? > > A: pa re xu ci > > B: i pa re nai ci i pa ze ja'ai ci > >I dunno what ja'ai is and don't feel like looking it up. ja'ai:nai::ja'a:na >This seems >highly contrived though. I probably would never say anything like that, but Lojbab seemed unable to find meaning in it. >Anyway, there's certainly tons of weird >things which would need to be explained (ku nai, pi'e nai, la/le/etc nai, >.inai, mi nai, la'e nai di'u, jai nai, etc etc). I see how many of those could be quite useful. > > Why is that not correct? The parser can't tell {je} appart from {ja}, > >This is just false. The parser can and does know the difference >between {je} and {ja}---that's how it prints either "and" or "or" >as the gloss. Then in the same way it can also see {jenai} as different from {je}. > > why is it such a big deal if it can't tell them appart from {jenai} > > either? {naje} does not imply {na(je)}, so {najenai} will not imply > > {na(jenai)} either. > >najenai with nai in UI *does* require na(jenai), because the free >modifier applies to the word before the word gets reduced into >whatever other rule. {naje} is not the negation of {je}. Similarly, {najenai} would not be the negation of {jenai}, which seemed to be Lojbab's objection. >The parser certainly *can* hack around this >and know whether the "je" has a nai attached to it, but it's a lot >less clean, and makes the parse tree not really reflect the grammatical >structure. I don't understand how that would be a hack. >(as lojbab said, the structure of it is just "na je" >and not "na je nai"). {je}, {na je}, {je nai} and {na je nai} all have the same structure, they are all connectives, binary operators. That wouldn't change if {nai} was in UI. mu'o mi'e xorxes _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail