From pycyn@aol.com Sat Oct 06 14:19:12 2001 Return-Path: X-Sender: Pycyn@aol.com X-Apparently-To: lojban@yahoogroups.com Received: (EGP: mail-7_4_1); 6 Oct 2001 21:16:44 -0000 Received: (qmail 49177 invoked from network); 6 Oct 2001 21:16:44 -0000 Received: from unknown (10.1.10.142) by 10.1.1.221 with QMQP; 6 Oct 2001 21:16:44 -0000 Received: from unknown (HELO imo-r04.mx.aol.com) (152.163.225.100) by mta3 with SMTP; 6 Oct 2001 21:19:11 -0000 Received: from Pycyn@aol.com by imo-r04.mx.aol.com (mail_out_v31_r1.7.) id r.88.d67e295 (17381) for ; Sat, 6 Oct 2001 17:19:04 -0400 (EDT) Message-ID: <88.d67e295.28f0cf48@aol.com> Date: Sat, 6 Oct 2001 17:19:04 EDT Subject: Re: [lojban] On functions to various types of things. To: lojban@yahoogroups.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_88.d67e295.28f0cf48_boundary" X-Mailer: AOL 6.0 for Windows US sub 10535 From: pycyn@aol.com --part1_88.d67e295.28f0cf48_boundary Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Irony is dead. The point of the "proposal" was to be so absurd th= at=20 everyone would say "Wait! Why clutter up everything that is working fine ju= st=20 to feel comfortable about one case that is just like all the rest but gives= =20 me the creepies" and we could go on about the business. Now we have someon= e=20 taking the "suggestion" seriously and rejecting it across the board because= =20 it doesn't look grammatical (though it is), another person noting that it i= s=20 grammatical but rejecting it because (well, I'm not exacrly sure, but mainl= y=20 I think) because it ain't the way we used to do it (though the one case has= =20 not been done before). And finally someone (or both of these two, actually= )=20 proposing setting the one case out specially again (thereby missing the who= le=20 point -- again) to be treated in Mex. So, all I can do is recommend treati= ng=20 all functions, except {ka}, which already has a special mark, in MEX. Whic= h=20 ain't the way we used to do it but is at least consistent and coherent. Is= =20 old {ka} now {na'u du'u} or {du'u na'u}? I think it may make a difference = in=20 dealing with indirect questions, but either is so ugly it hardly matters. &: <> One of the virtues elsewhere has been that the form marked the sort of=20 > thing that came out as values {du'u} and propositions, {ni} and qunatitie= s,=20 > and so on.=A0=A0=20 I can see the force of this argument and the virtue of keeping it in mind when seeking ways to refer to functions that, when applied, yield sumti.> Most of these critters yield sumti in their regular use; this is not a=20 special case. <1. Lojban has no way to express the mother-of function applied to an=20 argument. When I said this before, you replied: > applied function rather than only as a predicate. E.g. if *{mamta la=20 > djan} functioned as a sumti that referred to the mother of John. That=20 > seems to be how you conceive of {le mamta be la djan}, but really that=20 > means "x is such that it is nonveridically said to be the case that x=20 > mamta la djan", where x is not bound by a quantifier.>=20 > > Well, as you are wont to say, that *is* how Lojban uses {mamta} as an=20 > applied function.=A0 That role may not follow strictly from the literal=20 > meaning of the terms but it is a role that the expression plays -- look=20 > at a clear case like {le sumji be le re li mu}. (I would argue that "is=20 > non-veridically said to be" is suspect loading, "that the speaker is usin= g"=20 > is safer, for the speaker may use it just because it is the veridical thi= ng=20 > to say -- and usually does, byt the way).=A0=A0=20 "le sumji" is a poor choice of gadri, though I concede that it is hallowed by usage. At any rate, we seem to agree that Lojban has no way to express=20 the mother-of function applied to an argument, and that in those circumstan= ces where we would use a way to express the mother-of function applied to an=20 argument, if we had such a way, we instead use "le mamta be" (or similar with some other gadri).> As I have said -- while conceding taht {le} is saddled with all kinds of=20 problems, but pointing to its traditonal usage -- {le mamta be ...} is=20 exactly how Lojban deals with the mother-of function applied to an argument= .=20=20 The problem is to find a way to talk about the mother-of function all by=20 itself, as we talk about the is-big function or the size function so easily= .=20 We also want to do it in a way that parallels these othre cases, since they= =20 occur in parallel situations (pur storeies about W and Jeb and Chelsea, for= =20 the most part, so far).=20 <2. Lojban's prime exemplars of functions are its mex operators, and Lojban provides a way to convert a selbri to operator: {na'u mamta}. (I don't see that we need {na'u mamta (be?) ce'u}.)> Actually, these have almost never been used and are certainly a lot less=20 common than {ce'u} functions built from ordinary predicates <3. There seems to be no easy way to convert an operator to a sumti. Does=20 {li} tolerate an operandless operator as complement -- {li na'u mamta}? Otherwise, {li ni'e nu'a na'u mamta} converts from operator to sumti.> {li} is jsut the sort of thing that I was afraid might happen with Lojbab's= =20 suggestion, though I am happy to see that Lojbab doesn't accept it. For th= e=20 final case you give, I'm not sure you need {ni'e}, then the {nu'a na'u}=20 cancel out and the {li} , bing inappropriate, is relaced by {le} to get wha= t=20 we started with in the friest place {le mamta}. And Farmer Brown is geting= =20 angry with all the troops gallumphing in his barnyard. <4. The applied function could be expressed as {li na'u mamta mo'e la djan}= .> Or, in a rare flash of sanity, {le mamta be la djan}. lojbab: Of course, I am inclined to say that this is just one of those ornamentatio= ns=20 designed into the langauge and point to all the cases where it is so used,= =20 wondering why it cannot be used in this most basic place. <>1. Lojban has no way to express the mother-of function applied to an=20 argument. This is notationally y=3Dmother(x) correct? If so, then it is precisely mekso, and you can convert the predicate with=20 ce'u as a single thing, or convert all the pieces to an Polish notation=20 expression with "mamta" as the operator and 1 operand for the x2 (this=20 loses the number-of-arguments semantics info since it is purely notational= =20 and the functions can have arbitrary numbers of arguments)> I'd like to see the Lojban here, the shifting this and calling it that=20 described has left me in a dither about just what I should actually SAY. <>3. There seems to be no easy way to convert an operator to a sumti. You can convert ANYTHING in Mex.=A0 You probably want to use me'o and leave= =20 the operands unfilled.> Well, not, not {me'o na'u mamta}, since that is just the expression; rather= =20 {la'e me'o na'u mamta}. Will someone please tell me why all this trouble f= or=20 this particular issue when all the corresponding ones, with every other kin= d=20 of value, are dealt with just by putting {ce'u} in where the arguments go. --part1_88.d67e295.28f0cf48_boundary Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable <Sigh!>  Irony is dead.  The point of the "proposal" was = to be so absurd that everyone would say "Wait! Why clutter up everything th= at is working fine just to feel comfortable about one case that is just lik= e all the rest but gives me the creepies" and we could go on about the busi= ness.  Now we have someone taking the "suggestion" seriously and rejec= ting it across the board because it doesn't look grammatical (though it is)= , another person noting that it is grammatical but rejecting it because (we= ll, I'm not exacrly sure, but mainly I think) because it ain't the way we u= sed to do it (though the one case has not been done before).  And fina= lly someone (or both of these two, actually) proposing setting the one case= out specially again (thereby missing the whole point -- again) to be treat= ed in Mex.  So, all I can do is recommend treating all functions, exce= pt {ka}, which already has a special mark, in MEX.  Which ain't the wa= y we used to do it but is at least consistent and coherent. Is old {ka} now= {na'u du'u} or {du'u na'u}?  I think it may make a difference in deal= ing with indirect questions, but either is so ugly it hardly matters.

&:
<> One of the virtues elsewhere has been that the form marked the= sort of=20
> thing that came out as values {du'u} and propositions, {ni} and qu= natities,=20
> and so on.=A0=A0=20

I can see the force of this argument and the virtue of keeping it in mi= nd
when seeking ways to refer to functions that, when applied, yield sumti= .>

Most of these critters yield sumti in their regular use; this is not a = special case.

<1. Lojban has no way to express the mother-of function applied to a= n argument.

When I said this before, you replied:
> <I=20
> applied function rather than only as a predicate. E.g. if *{mamta = la=20
> djan} functioned as a sumti that referred to the mother of John. T= hat=20
> seems to be how you conceive of {le mamta be la djan}, but really = that=20
> means "x is such that it is nonveridically said to be the case tha= t x=20
> mamta la djan", where x is not bound by a quantifier.>=20
>
> Well, as you are wont to say, that *is* how Lojban uses {mamta} as= an=20
> applied function.=A0 That role may not follow strictly from the li= teral=20
> meaning of the terms but it is a role that the expression plays --= look=20
> at a clear case like {le sumji be le re li mu}. (I would argue tha= t "is=20
> non-veridically said to be" is suspect loading, "that the speaker = is using"=20
> is safer, for the speaker may use it just because it is the veridi= cal thing=20
> to say -- and usually does, byt the way).=A0=A0=20

"le sumji" is a poor choice of gadri, though I concede that it is hallo= wed
by usage. At any rate, we seem to agree that Lojban has no way to expre= ss=20
the mother-of function applied to an argument, and that in those circum= stances
where we would use a way to express the mother-of function applied to a= n=20
argument, if we had such a way, we instead use "le mamta be" (or simila= r
with some other gadri).>

As I have said -- while conceding taht {le} is saddled with all kinds o= f problems, but pointing to its traditonal usage -- {le mamta be ...} is ex= actly how Lojban deals with the mother-of function applied to an argument. =  The problem is to find a way to talk about the mother-of function all= by itself, as we talk about the is-big function or the size function so ea= sily. We also want to do it in a way that parallels these othre cases, sinc= e they occur in parallel situations (pur storeies about W and Jeb and Chels= ea, for the most part, so far).=20

<2. Lojban's prime exemplars of functions are its mex operators, and= Lojban
provides a way to convert a selbri to operator: {na'u mamta}. (I don't = see
that we need {na'u mamta (be?) ce'u}.)>

Actually, these have almost never been used and are certainly a lot les= s common than {ce'u} functions built from ordinary predicates

<3. There seems to be no easy way to convert an operator to a sumti.= Does=20
{li} tolerate an operandless operator as complement -- {li na'u mamta}?
Otherwise, {li ni'e nu'a na'u mamta} converts from operator to sumti.&g= t;

{li} is jsut the sort of thing that I was afraid might happen with Lojb= ab's suggestion, though I am happy to see that Lojbab doesn't accept it. &n= bsp;For the final case you give, I'm not sure you need {ni'e}, then the {nu= 'a na'u} cancel out and the {li} , bing inappropriate, is relaced by {le} t= o get what we started with in the friest place {le mamta}.  And Farmer= Brown is geting angry with all the troops gallumphing in his barnyard.

<4. The applied function could be expressed as {li na'u mamta mo'e l= a djan}.>

Or, in a rare flash of sanity, {le mamta be la djan}.

lojbab:

<So any time you want formal expression and it isn't a simple predic= ate or=20
one of the ornamentations thereof that we designed into the language, M= ex=20
is the way to go - or at least we hope so.>

Of course, I am inclined to say that this is just one of those ornament= ations designed into the langauge and point to all the cases where it is so= used, wondering why it cannot be used in this most basic place.

<>1. Lojban has no way to express the mother-of function applied = to an argument.

This is notationally
y=3Dmother(x)
correct?

If so, then it is precisely mekso, and you can convert the predicate wi= th=20
ce'u as a single thing, or convert all the pieces to an Polish notation= =20
expression with "mamta" as the operator and 1 operand for the x2 (this= =20
loses the number-of-arguments semantics info since it is purely notatio= nal=20
and the functions can have arbitrary numbers of arguments)>

I'd like to see the Lojban here, the shifting this and calling it that = described has left me in a dither about just what I should actually SAY.

<>3. There seems to be no easy way to convert an operator to a su= mti.

You can convert ANYTHING in Mex.=A0 You probably want to use me'o and l= eave=20
the operands unfilled.>

Well, not, not {me'o na'u mamta}, since that is just the expression; ra= ther {la'e me'o na'u mamta}.  Will someone please tell me why all this= trouble for this particular issue when all the corresponding ones, with ev= ery other kind of value,  are dealt with just by putting {ce'u} in whe= re the arguments go.





--part1_88.d67e295.28f0cf48_boundary--