From pycyn@aol.com Tue Mar 12 10:54:23 2002 Return-Path: X-Sender: Pycyn@aol.com X-Apparently-To: lojban@yahoogroups.com Received: (EGP: unknown); 12 Mar 2002 18:54:23 -0000 Received: (qmail 1278 invoked from network); 12 Mar 2002 18:54:21 -0000 Received: from unknown (216.115.97.172) by m10.grp.snv.yahoo.com with QMQP; 12 Mar 2002 18:54:21 -0000 Received: from unknown (HELO imo-d09.mx.aol.com) (205.188.157.41) by mta2.grp.snv.yahoo.com with SMTP; 12 Mar 2002 18:54:21 -0000 Received: from Pycyn@aol.com by imo-d09.mx.aol.com (mail_out_v32.5.) id r.a.1b73db0b (16932) for ; Tue, 12 Mar 2002 13:53:50 -0500 (EST) Message-ID: Date: Tue, 12 Mar 2002 13:53:50 EST Subject: Re: [lojban] More about quantifiers To: lojban@yahoogroups.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_a.1b73db0b.29bfa8be_boundary" X-Mailer: AOL 7.0 for Windows US sub 118 From: pycyn@aol.com X-Yahoo-Group-Post: member; u=2455001 X-Yahoo-Profile: kaliputra --part1_a.1b73db0b.29bfa8be_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 3/12/2002 12:18:36 PM Central Standard Time, jjllambias@hotmail.com writes: > The {lo su'o broda} forms in my system are just convenient > shortcuts. The full fledged forms will add {ganai da broda gi} > in front of the corresponding + form. > Now that is mucky. But it saves you yet another rule although at extreme cost. The predicate sumti - description sumti interchange is pretty automatic; shifting order would be a bit more complicated, but still falls under a straightforward rule. It may call for some further work. Or, if it gets to awful, we can leave the negation form unreduced, as you do in two cases. <>I think that extra effort is worth it to be able to tell >at a glance that a setence has existential import. I'm not sure it buys you even that. Just hide a negation a bit and at least for me it is not something you can tell at a glance: no broda me'iro da poi brode cu brodi Does that have existential import for brode? Can you really tell at a glance?> You have constructed a case where I have to stop and think a bit. But in your system, I always have to stop and think -- in fact recall the whole table to figure where this form fits in. To be sure, the prefixes forms would help, but are unwieldy (to be polite). --part1_a.1b73db0b.29bfa8be_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 3/12/2002 12:18:36 PM Central Standard Time, jjllambias@hotmail.com writes:


The {lo su'o broda} forms in my system are just convenient
shortcuts. The full fledged forms will add {ganai da broda gi}
in front of the corresponding + form.


Now that is mucky. But it saves you yet another rule although at extreme cost.

<The "exchange {Q da poi broda} and {Q broda}" bit is the ugly
step for me. When {broda} is a complex bridi, this may mean
adding lots of be-bei's and possibly having to do internal
rearrangments if {ke'a} is not the first sumti. It sounds like
a simple rule, but in practice it is not. It removes the
freedom to use the {poi} form as a stylistic variant, which
is all it is in my version.>

The predicate sumti - description sumti interchange is pretty automatic; shifting order would be a bit more complicated, but still falls under a straightforward rule.  It may call for some further work.  Or, if it gets to awful, we can leave the negation form unreduced, as you do in two cases.

<>I think that extra effort is worth it to be able to tell
>at a glance that a setence has existential import.

I'm not sure it buys you even that. Just hide a negation a
bit and at least for me it is not something you can tell at
a glance:

   no broda me'iro da poi brode cu brodi

Does that have existential import for brode? Can you really
tell at a glance?>

You have constructed a case where I have to stop and think a bit.  But in your system, I always have to stop and think -- in fact recall the whole table to figure where this form fits in.  To be sure, the prefixes forms would help, but are unwieldy (to be polite).



 --part1_a.1b73db0b.29bfa8be_boundary--