From pycyn@aol.com Wed Aug 29 08:21:45 2001 Return-Path: X-Sender: Pycyn@aol.com X-Apparently-To: lojban@yahoogroups.com Received: (EGP: mail-7_3_2); 29 Aug 2001 15:21:44 -0000 Received: (qmail 32344 invoked from network); 29 Aug 2001 15:18:19 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 29 Aug 2001 15:18:19 -0000 Received: from unknown (HELO imo-d09.mx.aol.com) (205.188.157.41) by mta1 with SMTP; 29 Aug 2001 15:18:19 -0000 Received: from Pycyn@aol.com by imo-d09.mx.aol.com (mail_out_v31_r1.4.) id r.129.3cd9e69 (4353) for ; Wed, 29 Aug 2001 11:18:14 -0400 (EDT) Message-ID: <129.3cd9e69.28be61b6@aol.com> Date: Wed, 29 Aug 2001 11:18:14 EDT Subject: Re: [lojban] Another stab at a Record on ce'u To: lojban@yahoogroups.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_129.3cd9e69.28be61b6_boundary" X-Mailer: AOL 6.0 for Windows US sub 10531 From: pycyn@aol.com X-Yahoo-Message-Num: 10245 --part1_129.3cd9e69.28be61b6_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 8/29/2001 8:15:24 AM Central Daylight Time, a.rosta@dtn.ntl.com writes: > You can't get rid of this imprecision without either (i) formulating rules > that are simple enough to be workable but constrain people to a degree > they won't accept, or (ii) formulating rules that are so complicated they'll > leak, and so complicated they'll be ignored. Leave ka for usage to decide. > Anything else, it transpires, is a waste of energy. > Well, it is nice to agree with And from time to time; it is a waste of energy. This was clear early on, but y'all kept at it and I tried to keep up, though all the wanderings to half a dozen (probably more) other points and back. You don't want a leaky {ka} (or any other leaky concepts -- well actually you want them all leaky but you want to pretend otherwise) but you don't want rules to keep them from being leaky (part of the evidence for the above parenthesis). As answer to the first part, I gave you a set of rules, based on your proposals -- incororating the best of the lot and them working to maximize efficiency and simplicity. Despite what And says, this set gives shorter forms than those using {si'o} and involves no conflicts. The main objection is to the first-{ce'u} abbreviation for an all {ce'u} form (at a glance, the only part anyone has actually thought through). That is quite detachable, though it is the best compromise in the given system (and, after all, the all {ce'u} form is the basic one in the language). If we only need that form occasionally, no much will be lost by writing in all the {ce'u}. So what about the rest, which are just a compliation of your suggestions? I suspect that y'all will reject them, but it would be nice to see some reasons given -- to go into the record, so that the next time this comes up we can say early on "This is a waste, we don't really want precision." --part1_129.3cd9e69.28be61b6_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 8/29/2001 8:15:24 AM Central Daylight Time,
a.rosta@dtn.ntl.com writes:



You can't get rid of this imprecision without either (i) formulating rules
that are simple enough to be workable but constrain people to a degree
they won't accept, or (ii) formulating rules that are so complicated they'll
leak, and so complicated they'll be ignored. Leave ka for usage to decide.
Anything else, it transpires, is a waste of energy.




Well, it is nice to agree with And from time to time; it is a waste of
energy.  This was clear early on, but y'all kept at it and I tried to keep
up, though all the wanderings to half a dozen (probably more) other points
and back.  
You don't want a leaky {ka} (or any other leaky concepts -- well actually you
want them all leaky but you want to pretend otherwise) but you don't want
rules to keep them from being leaky (part of the evidence for the above
parenthesis).  As answer to the first part, I gave you a set of rules, based
on your proposals -- incororating the best of the lot and them working to
maximize efficiency and simplicity.  Despite what And says, this set gives
shorter forms than those using {si'o} and involves no conflicts.
The main objection is to the first-{ce'u} abbreviation for an all {ce'u} form
(at a glance, the only part anyone has actually thought through).  That is
quite detachable, though it is the best compromise in the given system (and,
after all, the all {ce'u} form is the basic one in the language).  If we only
need that form occasionally, no much will be lost by writing in all the
{ce'u}.  So what about the rest, which are just a compliation of your
suggestions?  
I suspect that y'all will reject them, but it would be nice to see some
reasons given -- to go into the record, so that the next time this comes up
we can say early on "This is a waste, we don't really want precision." --part1_129.3cd9e69.28be61b6_boundary--