From pycyn@aol.com Mon Oct 01 12:51:58 2001
Return-Path: <Pycyn@aol.com>
X-Sender: Pycyn@aol.com
X-Apparently-To: lojban@yahoogroups.com
Received: (EGP: mail-7_4_1); 1 Oct 2001 19:50:10 -0000
Received: (qmail 13689 invoked from network); 1 Oct 2001 19:50:10 -0000
Received: from unknown (10.1.10.26)
  by 10.1.1.221 with QMQP; 1 Oct 2001 19:50:10 -0000
Received: from unknown (HELO imo-r07.mx.aol.com) (152.163.225.103)
  by mta1 with SMTP; 1 Oct 2001 19:51:57 -0000
Received: from Pycyn@aol.com
  by imo-r07.mx.aol.com (mail_out_v31_r1.7.) id r.16d.1bc5138 (3926)
  for <lojban@yahoogroups.com>; Mon, 1 Oct 2001 15:51:44 -0400 (EDT)
Message-ID: <16d.1bc5138.28ea234f@aol.com>
Date: Mon, 1 Oct 2001 15:51:43 EDT
Subject: Re: [lojban] Re: noxemol ce'u
To: lojban@yahoogroups.com
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="part1_16d.1bc5138.28ea234f_boundary"
X-Mailer: AOL 6.0 for Windows US sub 10535
From: pycyn@aol.com

--part1_16d.1bc5138.28ea234f_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

In a message dated 10/1/2001 12:29:45 PM Central Daylight Time, 
jjllambias@hotmail.com writes:


> But something _is_ thrown out! We could no longer
> use {le ka le mamta be ce'u cu melbi} for "the property
> of having a beautiful mother". That's the main reason I
> don't want to take {le mamta be ce'u} as a function.
> 

Well, no one has used it yet, so it can't exactly be thrown out, not yet 
being in. But moe to the point, we have a perfectly good way of saying it, 
so it is not lost -- and we gain a new thing we did not have before. 

<There's also the less important matter, but still significant,
that while you get ^xf(x), there's no equivalent way of
getting ^xf(g(x)).

It just wouldn't fit with the rest of the language if ce'u
had no prenex to hang from, and {le} does not provide one.>

Now, this is a genuine problem, since I don't see how to get {ce'u goi cy 
zo'u} in with {le}, either before or after, unless I mess a bit with relative 
clauses, which look suspicious. Hmmmm



--part1_16d.1bc5138.28ea234f_boundary
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

<HTML><FONT FACE=arial,helvetica><BODY BGCOLOR="#ffffff"><FONT SIZE=2>In a message dated 10/1/2001 12:29:45 PM Central Daylight Time, jjllambias@hotmail.com writes:
<BR>
<BR>
<BR><BLOCKQUOTE TYPE=CITE style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">But something _is_ thrown out! We could no longer
<BR>use {le ka le mamta be ce'u cu melbi} for "the property
<BR>of having a beautiful mother". That's the main reason I
<BR>don't want to take {le mamta be ce'u} as a function.
<BR></BLOCKQUOTE>
<BR>
<BR>Well, no one has used it yet, so it can't exactly be thrown out, not yet being in. &nbsp;But moe to the point, we have a perfectly good way of saying it, so it is not lost -- and we gain a new thing we did not have before. &nbsp;
<BR>
<BR>&lt;There's also the less important matter, but still significant,
<BR>that while you get ^xf(x), there's no equivalent way of
<BR>getting ^xf(g(x)).
<BR>
<BR>It just wouldn't fit with the rest of the language if ce'u
<BR>had no prenex to hang from, and {le} does not provide one.&gt;
<BR>
<BR>Now, this is a genuine problem, since I don't see how to get {ce'u goi cy zo'u} in with {le}, either before or after, unless I mess a bit with relative clauses, which look suspicious. &nbsp;Hmmmm
<BR>
<BR></FONT></HTML>

--part1_16d.1bc5138.28ea234f_boundary--

