From pycyn@aol.com Thu Sep 19 06:32:39 2002 Return-Path: X-Sender: Pycyn@aol.com X-Apparently-To: lojban@yahoogroups.com Received: (EGP: mail-8_1_1_3); 19 Sep 2002 13:32:39 -0000 Received: (qmail 20675 invoked from network); 19 Sep 2002 13:32:39 -0000 Received: from unknown (66.218.66.218) by m5.grp.scd.yahoo.com with QMQP; 19 Sep 2002 13:32:39 -0000 Received: from unknown (HELO imo-r05.mx.aol.com) (152.163.225.101) by mta3.grp.scd.yahoo.com with SMTP; 19 Sep 2002 13:32:39 -0000 Received: from Pycyn@aol.com by imo-r05.mx.aol.com (mail_out_v34.10.) id r.21.2436a39c (18707) for ; Thu, 19 Sep 2002 09:32:22 -0400 (EDT) Message-ID: <21.2436a39c.2abb2be6@aol.com> Date: Thu, 19 Sep 2002 09:32:22 EDT Subject: Re: [lojban] ka versus du'u To: lojban@yahoogroups.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_21.2436a39c.2abb2be6_boundary" X-Mailer: AOL 7.0 for Windows US sub 10509 From: pycyn@aol.com X-Yahoo-Group-Post: member; u=2455001 X-Yahoo-Profile: kaliputra --part1_21.2436a39c.2abb2be6_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 9/19/2002 5:52:43 AM Central Daylight Time, nessus@free.fr writes: << But I do not want to trigger again a discussion you had before: maybe> > you could just give me a reference in the list archive. Or maybe pc > wrote a summary of this discussion issues, like some others I found > in the archives. >> pc wrote several tentative summaries of the discussion, all of which were rejected by a large part of the discussants -- including one which exactly met the conditions the discussants claimed to have agreed about. The result is that {du'u} and {ka} are used in at least three different ways each (though I think there were four parties in the discussion) and, if you don't know the party of your interlocutor, you can get a wrong reading occasionally. By and large, though, if you see a {ce'u} in either context, it is a property being talked about. If you see no {ce'u} in a {du'u} clause, it is likely not to be a property, with a small but significant margin of error. {ka} is always some property of something, but which property and of what is not always clear, since {ce'u}s appear and disappear in the same context with amazing dexterity. So, for use, whatever you do, put in all your {ce'u}s. << A property abstraction is not the same as a predication abstraction. (an indication of this seems to be that a useful x2 place has be given to du'u and not to ka). And on the other hand I see no reference in the book for the use of ce'u with du'u. >> CLL is very quiet about {ce'u}, talking about it only in terms of {ka}, but also talking about {ka} without {ce'u} or any place for it. The use with {du'u} -- and eventually with any abstraction --, while allowed for in CLL, was developed from the post-book discussion that took off from the understanding of {ce'u} as a lambda'd variable in the lambda calculus (the one about abstractions, not the one about probabilities). {ce'u} doesn't work well in that role if you have occasions to want to bind two places the same way -- and pretty scary if you want to do that twice: \x\yFxyyx, is just hard to say in Lojban, though it can be done. That a property abstraction is not the same as a propositonal function is a contentious claim, though, amazingly, not one that was raised in the earlier discussion (I think). [I don't have reference numbers for the discussion but it seems to have stretch from August last year to April this, with a couple score of entries] The second place on {du'u} seems to have a certain use in mind, which is not this one, but is compatible with it (but almost never used, for obvious reasons). --part1_21.2436a39c.2abb2be6_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 9/19/2002 5:52:43 AM Central Daylight Time, nessus@free.fr writes:

<<

But I do not want to trigger again a discussion you had before: maybe

you could just give me a reference in the list archive. Or maybe pc
wrote a summary of this discussion issues, like some others I found
in the archives.

>>
pc wrote several tentative summaries of the discussion, all of which were rejected by a large part of the discussants -- including one which exactly met the conditions the discussants claimed to have agreed about.  The result is that {du'u} and {ka} are used in at least three different ways each (though I think there were four parties in the discussion) and, if you don't know the party of your interlocutor, you can get a wrong reading occasionally.  By and large, though, if you see a {ce'u} in either context, it is a property being talked about.  If you see no {ce'u} in a {du'u} clause, it is likely not to be a property, with a small but significant margin of error.  {ka} is always some property of something, but which property and of what is not always clear, since {ce'u}s appear and disappear in the same context with amazing dexterity.  So, for use, whatever you do, put in all your {ce'u}s.

<<
A property abstraction is not the same as a predication abstraction.
(an indication of this seems to be that a useful  x2 place has be given
to du'u and not to ka).
And on the other hand I see no reference in the book for the use of ce'u
with du'u.
>>
CLL is very quiet about {ce'u}, talking about it only in terms of {ka}, but also talking about {ka} without {ce'u} or any place for it.  The use with {du'u} -- and eventually with any abstraction --, while allowed for in CLL, was developed from the post-book discussion that took off from the understanding of {ce'u} as a lambda'd variable in the lambda calculus (the one about abstractions, not the one about probabilities). {ce'u} doesn't work well in that role if you have occasions to want to bind two places the same way -- and pretty scary if you want to do that twice: \x\yFxyyx, is just hard to say in Lojban, though it can be done.
That a property abstraction is not the same as a propositonal function is a contentious claim, though, amazingly, not one that was raised in the earlier discussion (I think). [I don't have reference numbers for the discussion but it seems to have stretch from August last year to April this, with a couple score of entries]  The second place on {du'u} seems to have a certain use in mind, which is not this one, but is compatible with it (but almost never used, for obvious reasons).
--part1_21.2436a39c.2abb2be6_boundary--