From lojban-out@lojban.org Tue Dec 03 22:55:36 2002
Return-Path: <lojban-out@lojban.org>
X-Sender: lojban-out@lojban.org
X-Apparently-To: lojban@yahoogroups.com
Received: (EGP: mail-8_2_3_0); 4 Dec 2002 06:55:36 -0000
Received: (qmail 96917 invoked from network); 4 Dec 2002 06:55:35 -0000
Received: from unknown (66.218.66.216)
  by m3.grp.scd.yahoo.com with QMQP; 4 Dec 2002 06:55:35 -0000
Received: from unknown (HELO digitalkingdom.org) (204.152.186.175)
  by mta1.grp.scd.yahoo.com with SMTP; 4 Dec 2002 06:55:35 -0000
Received: from lojban-out by digitalkingdom.org with local (Exim 4.05)
  id 18JTRX-0005wF-00
  for lojban@yahoogroups.com; Tue, 03 Dec 2002 22:55:35 -0800
Received: from digitalkingdom.org ([204.152.186.175] helo=chain)
  by digitalkingdom.org with esmtp (Exim 4.05)
  id 18JTRS-0005vx-00; Tue, 03 Dec 2002 22:55:30 -0800
Received: with ECARTIS (v1.0.0; list lojban-list); Tue, 03 Dec 2002 22:55:29 -0800 (PST)
Received: from cs6668125-184.austin.rr.com ([66.68.125.184] ident=root)
  by digitalkingdom.org with esmtp (Exim 4.05)
  id 18JTRN-0005vo-00
  for lojban-list@lojban.org; Tue, 03 Dec 2002 22:55:25 -0800
Received: from cs6668125-184.austin.rr.com (asdf@localhost [127.0.0.1])
  by cs6668125-184.austin.rr.com (8.12.3/8.12.3) with ESMTP id gB471OG9060364
  for <lojban-list@lojban.org>; Wed, 4 Dec 2002 01:01:24 -0600 (CST)
  (envelope-from fracture@cs6668125-184.austin.rr.com)
Received: (from fracture@localhost)
  by cs6668125-184.austin.rr.com (8.12.3/8.12.3/Submit) id gB471Mfg060358
  for lojban-list@lojban.org; Wed, 4 Dec 2002 01:01:22 -0600 (CST)
Date: Wed, 4 Dec 2002 01:01:22 -0600
To: lojban-list@lojban.org
Subject: [lojban] Re: ka'enai (was: Re: A question on the new baseline policy)
Message-ID: <20021204070122.GA60012@allusion.net>
References: <F8583tmTRv2gvOpPXGh0001603e@hotmail.com>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;	protocol="application/pgp-signature"; boundary="Qxx1br4bt0+wmkIi"
Content-Disposition: inline
In-Reply-To: <F8583tmTRv2gvOpPXGh0001603e@hotmail.com>
User-Agent: Mutt/1.5.1i
X-archive-position: 2998
X-ecartis-version: Ecartis v1.0.0
Sender: lojban-list-bounce@lojban.org
Errors-to: lojban-list-bounce@lojban.org
X-original-sender: fracture@allusion.net
Precedence: bulk
X-list: lojban-list
X-eGroups-From: Jordan DeLong <fracture@allusion.net>
From: Jordan DeLong <lojban-out@lojban.org>
Reply-To: fracture@allusion.net
X-Yahoo-Group-Post: member; u=116389790
X-Yahoo-Profile: lojban_out

--Qxx1br4bt0+wmkIi
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Dec 03, 2002 at 07:42:28PM +0000, Jorge Llambias wrote:
> la lojbab cusku di'e
> >I think that NAI treated as a UI would cause more (semantics) problems t=
han
> >you can imagine (and we did consider it, albeit VERY briefly). You are =
the
> >one who wants better semantics definition. Grammatically it would be a
> >major change because NAI is in so many rules.
>=20
> It is precisely because it is in so many rules, that it is difficult
> to learn. For each rule, you have to learn whether or not it allows
> NAI. Moving NAI to UI may be a major change but it would be one that
> simplifies the grammar, and which is also fully backward compatible,
> so the best kind of change.

I think the first part is an overexaggeration of how difficult it
is to learn where NAI is allowed.

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.

> >pa re nai ci?
> >(pa re .uinai ci passes the parser)
>=20
> That could be used in this context, for example:
>=20
> 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. This seems
highly contrived though. 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).

> >It would mean that the logical connectives are handled by hodgepodge: je
> >and naje would be lexer tokens, but najenai would grammatically be naje
> >with an absorbed nai as part of the je hence implying "na (je nai)" whi=
ch
> >is not correct.
>=20
> 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.

> 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. 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. (as lojbab said, the structure of it is just "na je"
and not "na je nai").

[...]

--=20
Jordan DeLong - fracture@allusion.net
lu zo'o loi censa bakni cu terzba le zaltapla poi xagrai li'u
sei la mark. tuen. cusku

--Qxx1br4bt0+wmkIi
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (FreeBSD)

iD8DBQE97ahCDrrilS51AZ8RAtVYAJ44kgaBSKLkxU61nTvhbuCz9aymBQCgjZAV
GaUblX+tkY7LCvPG8M4nAok=
=TkZ9
-----END PGP SIGNATURE-----

--Qxx1br4bt0+wmkIi--

