From pycyn@aol.com Tue Oct 02 17:58:27 2001 Return-Path: X-Sender: Pycyn@aol.com X-Apparently-To: lojban@yahoogroups.com Received: (EGP: mail-7_4_1); 3 Oct 2001 00:58:27 -0000 Received: (qmail 50218 invoked from network); 3 Oct 2001 00:58:26 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 3 Oct 2001 00:58:26 -0000 Received: from unknown (HELO imo-r06.mx.aol.com) (152.163.225.102) by mta2 with SMTP; 3 Oct 2001 00:58:26 -0000 Received: from Pycyn@aol.com by imo-r06.mx.aol.com (mail_out_v31_r1.7.) id r.29.1b9d85da (4000) for ; Tue, 2 Oct 2001 20:58:22 -0400 (EDT) Message-ID: <29.1b9d85da.28ebbcad@aol.com> Date: Tue, 2 Oct 2001 20:58:21 EDT Subject: Re: [lojban] Re: noxemol ce'u To: lojban@yahoogroups.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_29.1b9d85da.28ebbcad_boundary" X-Mailer: AOL 6.0 for Windows US sub 10535 From: pycyn@aol.com --part1_29.1b9d85da.28ebbcad_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. > > 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. > Still a good point, but now one easily solved. We give {ce'u} the subscripting pattern of one of those annoying backcounting (upcounting) anaphora, so that it is marked for depth -- or rather bouyance. ^xFf> is {ce'u xire}, F^xf> is {ce'u xipa} and Ff<^xg> is just {ce'u}. All desiderata restored and much more tidily (and {goi cy} can go in anyhwere to deal wiht coreference). --part1_29.1b9d85da.28ebbcad_boundary Content-Type: text/html; 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.

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.


Still a good point, but now one easily solved.  We give {ce'u} the subscripting pattern of one of those annoying backcounting (upcounting) anaphora, so that it is marked for depth -- or rather bouyance.  ^xFf<g<x>> is {ce'u xire}, F^xf<g<x>> is {ce'u xipa} and
Ff<^xg<x>> is just {ce'u}.  All desiderata restored and much more tidily (and {goi cy} can go in anyhwere to deal wiht coreference).
--part1_29.1b9d85da.28ebbcad_boundary--