[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lojban] Re: ka'enai (was: Re: A question on the new baseline policy)



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 than
> >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.
> 
> 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)
> 
> That could be used in this context, for example:
> 
> 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)" which
> >is not correct.
> 
> 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").

[...]

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

Attachment: pgpgPMRQdNiUe.pgp
Description: PGP signature