From pycyn@aol.com Wed Aug 29 08:22:16 2001 Return-Path: X-Sender: Pycyn@aol.com X-Apparently-To: lojban@yahoogroups.com Received: (EGP: mail-7_3_2); 29 Aug 2001 15:22:16 -0000 Received: (qmail 71875 invoked from network); 29 Aug 2001 15:18:44 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 29 Aug 2001 15:18:44 -0000 Received: from unknown (HELO imo-r02.mx.aol.com) (152.163.225.98) by mta3 with SMTP; 29 Aug 2001 15:18:43 -0000 Received: from Pycyn@aol.com by imo-r02.mx.aol.com (mail_out_v31_r1.4.) id r.112.3dda3a5 (4353) for ; Wed, 29 Aug 2001 11:18:25 -0400 (EDT) Message-ID: <112.3dda3a5.28be61c1@aol.com> Date: Wed, 29 Aug 2001 11:18:25 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_112.3dda3a5.28be61c1_boundary" X-Mailer: AOL 6.0 for Windows US sub 10531 From: pycyn@aol.com --part1_112.3dda3a5.28be61c1_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 8/28/2001 11:40:23 PM Central Daylight Time, rob@twcny.rr.com writes: > On Tue, Aug 28, 2001 at 08:51:39PM -0400, pycyn@aol.com wrote: > > Simple, but unreliable ("where context indisputably demands" is going to > take > > in a lot of cases for some folk, none for others). So use the rule that > > covers all the cases -- I've offered two that don't use up {si'o} or > anything > > else and rarely require more than three or four syllables, regardless how > > many {ce'u} are needed. And agree with the first clause of yours (as it > must > > to meet the problems conditions). Now, what is wrong with these > proposals, > > especially the second? > > In recent Lojban text, people have been using {ka ce'u klama} to make it > entirely clear. There was an assumption that if you specify a ce'u, you > don't > need any interpretive rules to decide where the ce'u goes. The interpretive > conventions have been about what to do _in the absence of ce'u_. Exactly so. So, if you use {ce'u} wherever you intend one, then you have no need for conventions -- provided there are no conventions around that get in the way. So, I take this as an objection to the "all {ce'u}" convention at the end of my summary. OK, drop that. Then your claim is perfectly clear. In fact that does help warn people that you are not using a convention, probably also a good thing to do. > > Your idea points at them and says "Nope, you're wrong. {ka ce'u klama} > actually > means {ka ce'u klama ce'u ce'u ce'u ce'u}". And for what benefit? Just to > make > it really easy to have an all-ce'u bridi, which I still haven't seen a > plausible use for besides talking about the bridi itself. (For which I would > prefer {la'e zo klama}). IF you use the conventions. I like {la'e zo klama} better, too, but it is not a predicate, as {ka ce'u klama ce'u ce'u ce'u} is. That needs fixing (preferably not wiht {me}). > > And the idea of a ce'u that you _have_ to elide is just absurd. > {ka klama} = {ka ce'u klama} > {ka ce'u klama} = {ka ce'u klama ce'u ce'u ce'u ce'u} > > If you mean {ka ce'u klama}, you can't say it, and if you say it, you don't > mean it. How does this make anything clearer? Dropping the full {ce'u} proposal (I thought it was kinda cute, but I was clearly wrong, regardless of the parameters of the task), that initial {ce'u} becomes a warning that you are not using the convention and thus holds you to every {ce'u} you say and not one more. > > Incidentally, since you disagree with the idea of context demanding a > two-{ce'u} bridi, how would you state one under your proposal? If you state > both {ce'u}s, all the other places get {ce'u}-d as well. > {ka broda fe ce'u} --part1_112.3dda3a5.28be61c1_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 8/28/2001 11:40:23 PM Central Daylight Time,
rob@twcny.rr.com writes:

On Tue, Aug 28, 2001 at 08:51:39PM -0400, pycyn@aol.com wrote:
> Simple, but unreliable ("where context indisputably demands" is going to
take
> in a lot of cases for some folk, none for others). So use the rule that
> covers all the cases -- I've offered two that don't use up {si'o} or
anything
> else and rarely require more than three or four syllables, regardless how
> many {ce'u} are needed. And agree with the first clause of yours (as it
must
> to meet the problems conditions). Now, what is wrong with these
proposals,
> especially the second?

In recent Lojban text, people have been using {ka ce'u klama} to make it
entirely clear. There was an assumption that if you specify a ce'u, you
don't
need any interpretive rules to decide where the ce'u goes. The interpretive
conventions have been about what to do _in the absence of ce'u_.

Exactly so. So, if you use {ce'u} wherever you intend one, then you have no
need for conventions -- provided there are no conventions around that get in
the way. So, I take this as an objection to the "all {ce'u}" convention at
the end of my summary. OK, drop that. Then your claim is perfectly clear.
In fact that does help warn people that you are not using a convention,
probably also a good thing to do.

Your idea points at them and says "Nope, you're wrong. {ka ce'u klama}
actually
means {ka ce'u klama ce'u ce'u ce'u ce'u}". And for what benefit? Just to
make
it really easy to have an all-ce'u bridi, which I still haven't seen a
plausible use for besides talking about the bridi itself. (For which I would
prefer {la'e zo klama}).

IF you use the conventions. I like {la'e zo klama} better, too, but it is
not a predicate, as {ka ce'u klama ce'u ce'u ce'u} is. That needs fixing
(preferably not wiht {me}).

And the idea of a ce'u that you _have_ to elide is just absurd.
{ka klama} = {ka ce'u klama}
{ka ce'u klama} = {ka ce'u klama ce'u ce'u ce'u ce'u}

If you mean {ka ce'u klama}, you can't say it, and if you say it, you don't
mean it. How does this make anything clearer?

Dropping the full {ce'u} proposal (I thought it was kinda cute, but I was
clearly wrong, regardless of the parameters of the task), that initial {ce'u}
becomes a warning that you are not using the convention and thus holds you to
every {ce'u} you say and not one more.

Incidentally, since you disagree with the idea of context demanding a
two-{ce'u} bridi, how would you state one under your proposal? If you state
both {ce'u}s, all the other places get {ce'u}-d as well.

{ka broda fe ce'u}
--part1_112.3dda3a5.28be61c1_boundary--