From pycyn@aol.com Wed Aug 29 16:32:52 2001 Return-Path: X-Sender: Pycyn@aol.com X-Apparently-To: lojban@yahoogroups.com Received: (EGP: mail-7_3_2); 29 Aug 2001 23:32:51 -0000 Received: (qmail 39313 invoked from network); 29 Aug 2001 23:32:51 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 29 Aug 2001 23:32:51 -0000 Received: from unknown (HELO imo-r04.mx.aol.com) (152.163.225.100) by mta2 with SMTP; 29 Aug 2001 23:32:50 -0000 Received: from Pycyn@aol.com by imo-r04.mx.aol.com (mail_out_v31_r1.4.) id r.83.f3ba66c (3893) for ; Wed, 29 Aug 2001 19:32:44 -0400 (EDT) Message-ID: <83.f3ba66c.28bed59c@aol.com> Date: Wed, 29 Aug 2001 19:32:44 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_83.f3ba66c.28bed59c_boundary" X-Mailer: AOL 6.0 for Windows US sub 10531 From: pycyn@aol.com X-Yahoo-Message-Num: 10281 --part1_83.f3ba66c.28bed59c_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 8/29/2001 3:48:49 PM Central Daylight Time, a.rosta@dtn.ntl.com writes: > Before this debate began, rule 1 was NOT established or agreed on, and > hence it was possible that an empty place could be filled with a ce'u. > Depends upon when you think this debate began. This point could not have arisen before someone actually said that {du'u} is just {ka} with... Before THAT comment was made, I think point 1 was pretty much agreed on -- once {ce'u} came tyo be understood at all, that is. Is that a threat there will be such a thread, separate from {ce'u}? But, if so, didn't you just object to doing a gadri+ sumti-tail for "the typical"? Ah, the loss of community memory (and thus the need to repeat our mistakes, I suppose). Nalgol is the language "to improve a minor point in Loglan" by totally redoing a mass of major design features. The original one was, I think, Jim Carter's back in the late 70s. We haven't had occasion to mention this typical constructed language phenomenon in Lojban much since the base-lining (and before it was part of the process), but recently there seems to have been a spate of ever more aggressive cases which now seem to call the word back into use. Or should we shift to Nabjol? I think not; the chance to shoot at the languages of the 60s and 70s is still to good to pass by. --part1_83.f3ba66c.28bed59c_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 8/29/2001 3:48:49 PM Central Daylight Time,
a.rosta@dtn.ntl.com writes:


Before this debate began, rule 1 was NOT established or agreed on, and
hence it was possible that an empty place could be filled with a ce'u.


Depends upon when you think this debate began.  This point could not have
arisen before someone actually said that {du'u} is just {ka} with... Before
THAT comment was made, I think point 1 was pretty much agreed on -- once
{ce'u} came tyo be understood at all, that is.

<This really belongs in a different thread about lo'e, but it does seem to me
that for any construct that focuses on x1, the proper way to handle it is
using our x1-focusing construction, viz. gadri + sumti-tail.>

Is that a threat there will be such a thread, separate from {ce'u}?  But, if
so, didn't you just object to doing a gadri+ sumti-tail for "the typical"?

<What is Nalgol?>

Ah, the loss of community memory (and thus the need to repeat our mistakes, I
suppose).  Nalgol is the language "to improve a minor point in Loglan" by
totally redoing a mass of major design features.  The original one was, I
think, Jim Carter's back in the late 70s.  We haven't had occasion to mention
this typical constructed language phenomenon in Lojban much since the
base-lining (and before it was part of the process), but recently there seems
to have been a spate of ever more aggressive cases which now seem to call the
word back into use.  Or should we shift to Nabjol? I think not; the chance to
shoot at the languages of the 60s and 70s is still to good to pass by.

--part1_83.f3ba66c.28bed59c_boundary--