From pycyn@aol.com Wed Sep 18 07:21:19 2002 Return-Path: X-Sender: Pycyn@aol.com X-Apparently-To: lojban@yahoogroups.com Received: (EGP: mail-8_1_1_3); 18 Sep 2002 14:21:19 -0000 Received: (qmail 31430 invoked from network); 18 Sep 2002 14:21:19 -0000 Received: from unknown (66.218.66.218) by m13.grp.scd.yahoo.com with QMQP; 18 Sep 2002 14:21:19 -0000 Received: from unknown (HELO imo-m05.mx.aol.com) (64.12.136.8) by mta3.grp.scd.yahoo.com with SMTP; 18 Sep 2002 14:21:18 -0000 Received: from Pycyn@aol.com by imo-m05.mx.aol.com (mail_out_v34.10.) id r.19d.8e35557 (4230) for ; Wed, 18 Sep 2002 10:21:13 -0400 (EDT) Message-ID: <19d.8e35557.2ab9e5d9@aol.com> Date: Wed, 18 Sep 2002 10:21:13 EDT Subject: Re: [lojban] Re: I like chocolate To: lojban@yahoogroups.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_19d.8e35557.2ab9e5d9_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_19d.8e35557.2ab9e5d9_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 9/18/2002 8:44:35 AM Central Daylight Time, nessus@free.fr writes: << > Sorry if my questions sound too basic: I am just trying to > follow the discussion and understand the different point of > views, being well aware that my lojban current understanding > may be inapropriate. > >> No question is too basic if it is giving someone problems and in this case everything gives problems. We are in fringe areas here, where xorxes is advocating and trying to explain and justify a deviation from standard Lojban (to Llamban or Andban or ...). Thus, some of the presuppostions in play may be non-standard and yet unexpressed (we three have been at this a long long time). << la xorxes cusku di'e> > To me {da zo'u broda tu'a da} makes > a different klaim than {broda tu'a da}, where the quantification > of {da} is within the {tu'a} abstraction. I don't know how > you can defend the {tu'a} expressions for intensional contexts > if you don't think so. I am lost here: I thought the grammar said clearly that in {da zo'u broda tu'a da} the {da zo'u} could be freely omitted with no change in semantic, and so I don't see how {broda tu'a da} could claim a different thing, intensional contexts or not. Or maybe I fail to read an other discussion where you agree on redefining this grammar point in intensional contexts. Could you give an example with true selbris where the two have to be different? >> The grammar clearly says a number of things that are not so in at least some cases (the most famous is that {a broda b} = (b se broda a} , which does not hold when a and b are bound in place with different quantifiers: {ro da prami de}, "Everybody loves somebody" is not the same as {de se prami ro da} "There is at least one persom whom everybody loves"). As for the quantifier bit, the grammar of intensional contexts has not been redefined, mainly because CLL does so little about defining it. So we say "clarified" instead of "changed." In any case, we would not want to go from {mi nitcu tu'a lo dinko} "I need a nail" (and any old one will do) to {da poi dinko zo'u mi nitcu da} "There is one particular nail I need" (or "some particular nails" but, in any case, nothing off the list will do). There are worse cases, where the embedded reference is to a non-existent, but the external reference is to an existent: {mi senva le du'u lo pavyselrorne klama mi} might well be true, but {da poi pavyselrorne zo'u mi sevna le du'u da klama mi} is not, since there are no unicorns. << > We can now give a precise definition of {broda} in terms > of {kairbroda}: > ko'a broda ko'e = ko'a kairbroda tu'o du'u ce'u du ko'e > ko'a is broda to ko'e = ko'a is broda to something that > has the property of being ko'e I don't understand your use of {tu'o} here. Is that what makes {du'u ce'u du k'oe} a true property? Or to say it differently, how do you get a property out of a predication abstraction? >> {tu'o}, the "null operand" (nowhere further explained) is used here as a vacuous PA. The grammar requires a descriptor or a number here, but the fact is that there is always exactly one thing satisfying this description, so why get involved with all the problems (quantifiers especially) that using a regular form involves? Thus And and xorxes. I am not perfectly sure that there is always only one and I don't know what {tu'o} commits me to, so I prefer to use {le}, though, when I am talking with the other two, I sometimes fall into their usage. --part1_19d.8e35557.2ab9e5d9_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 9/18/2002 8:44:35 AM Central Daylight Time, nessus@free.fr writes:

<<
Sorry if my questions sound too basic: I am just trying to
follow the discussion and understand the different point of
views, being well aware that my lojban current understanding
may be inapropriate.
>
>
No question is too basic if it is giving someone problems and in this case everything gives problems.  We are in fringe areas here, where xorxes is advocating and trying to  explain and justify a deviation from standard Lojban (to Llamban or Andban or ...).
Thus, some of the presuppostions in play may be non-standard and yet unexpressed (we three have been at this a long long time). 

<<
la xorxes cusku di'e>
> To me {da zo'u broda tu'a da} makes
> a different klaim than {broda tu'a da}, where the quantification
> of {da} is within the {tu'a} abstraction. I don't know how
> you can defend the {tu'a} expressions for intensional contexts
> if you don't think so.

I am lost here: I thought the grammar said clearly that in
{da zo'u broda tu'a da} the {da zo'u} could be freely omitted
with no change in semantic, and so I don't see how
{broda tu'a da} could claim a different thing, intensional contexts
or not. Or maybe I fail to read an other discussion where you
agree on redefining this grammar point in intensional contexts.
Could you give an example with true selbris where the two have
to be different?
>>
The grammar clearly says a number of things that are not so in at least some cases (the most famous is that {a broda b} = (b se broda a} , which does not hold when a and b are bound in place with different quantifiers: {ro da prami de}, "Everybody loves somebody" is not the same as {de se prami ro da} "There is at least one persom whom everybody loves"). 
As for the quantifier bit, the grammar of intensional contexts has not been redefined, mainly because CLL does so little about defining it.  So we say "clarified" instead of "changed."  In any case, we would not want to go from {mi nitcu tu'a lo dinko} "I need a nail" (and any old one will do) to {da poi dinko zo'u mi nitcu da} "There is one particular nail I need" (or "some particular nails" but, in any case, nothing off the list will do).  There are worse cases, where the embedded reference is to a non-existent, but the external reference is to an existent: {mi senva le du'u lo pavyselrorne klama mi} might well be  true, but {da poi pavyselrorne zo'u mi sevna le du'u da klama mi} is not, since there are no unicorns.

<<
> We can now give a precise definition of {broda} in terms
> of {kairbroda}:
> ko'a broda ko'e = ko'a kairbroda tu'o du'u ce'u du ko'e
> ko'a is broda to ko'e = ko'a is broda to something that
>                       has the property of being ko'e

I don't understand your use of {tu'o} here.  Is that what makes
{du'u ce'u du k'oe} a true property?  Or to say it differently,
how do you get a property out of a predication abstraction?
>>
{tu'o}, the "null operand" (nowhere further explained) is used here as a vacuous PA.  The grammar requires a descriptor or a number here, but the fact is that there is always exactly one thing satisfying this description, so why get involved with all the problems (quantifiers especially) that using a regular form involves?  Thus And and xorxes.  I am not perfectly sure that there is always only one and I don't know what {tu'o} commits me to, so I prefer to use {le}, though, when I am talking with the other two, I sometimes fall into their usage.




 --part1_19d.8e35557.2ab9e5d9_boundary--