From pycyn@aol.com Mon Oct 08 16:53:34 2001 Return-Path: X-Sender: Pycyn@aol.com X-Apparently-To: lojban@yahoogroups.com Received: (EGP: mail-7_4_1); 8 Oct 2001 23:53:34 -0000 Received: (qmail 78237 invoked from network); 8 Oct 2001 23:52:59 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 8 Oct 2001 23:52:59 -0000 Received: from unknown (HELO imo-d03.mx.aol.com) (205.188.157.35) by mta1 with SMTP; 8 Oct 2001 23:52:59 -0000 Received: from Pycyn@aol.com by imo-d03.mx.aol.com (mail_out_v31_r1.7.) id r.2f.1bd84b72 (7878) for ; Mon, 8 Oct 2001 19:52:57 -0400 (EDT) Message-ID: <2f.1bd84b72.28f39658@aol.com> Date: Mon, 8 Oct 2001 19:52:56 EDT Subject: Re: [lojban] Re: fancu To: lojban@yahoogroups.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_2f.1bd84b72.28f39658_boundary" X-Mailer: AOL 6.0 for Windows US sub 10535 From: pycyn@aol.com --part1_2f.1bd84b72.28f39658_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 10/8/2001 5:20:51 PM Central Daylight Time, jjllambias@hotmail.com writes: > ({na'i mi ...} otherwise na'i attaches to {mi} only.) > Yes, I keep wanting to assimilate it to {na}. Yes, that is an answer that John might know -- not the only one that works, of course. Well, i don't see it, since ther are perfectly good answers (in my view -- yours too apparently) that John has available to know that settle the issue. But this may be a real usage issue -- assuming there are no theoretical aftereffects (I don't think that risinging presuppositions in this case need to force them in others where they clearly don't apply, e.g., in "The claim that I have stopped beating my wife is bogus." <>(by the way, >{darxi} by itself is not good for "beating" in htis context, nor is {co'u} >for "stop") Maybe {co'u ta'e darxi}?> Better, though "hit" is not the same as "beat" either. <>The fact that a question does not meet its presuppositions does not make it >less of a question, it merely makes it one that has a peculiar correct >answer. One that has no correct logical answer, in my view. Correct illocutionary answers it has aplenty, I agree.> One of the reasons I prefer illocutionary answers. It is the insistence on logical answers that gives these kinds of questions their force and they should be stripped of it. --part1_2f.1bd84b72.28f39658_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 10/8/2001 5:20:51 PM Central Daylight Time, jjllambias@hotmail.com writes:


({na'i mi ...} otherwise na'i attaches to {mi} only.)

Yes, I keep wanting to assimilate it to {na}.

<But then that supports my point. Or do you mean that to be the
answer that John knows? >

Yes, that is an answer that John might know -- not the only one that works, of course.

<I still think "Does John know whether you
have stopped beating your wife?" has itself a presupposition which
is not fully buried inside the indirect question. I would answer
{na'i}, not {go'i}.>

Well, i don't see it, since ther are perfectly good answers (in my view -- yours too apparently) that John has available to know that settle the issue.  But this may be a real usage issue -- assuming there are no theoretical aftereffects (I don't think that risinging presuppositions in this case need to force them in others where they clearly don't apply, e.g., in "The claim that I have stopped beating my wife is bogus."

<>(by the way,
>{darxi} by itself is not good for "beating" in htis context, nor is {co'u}
>for "stop")

Maybe {co'u ta'e darxi}?>

Better, though "hit" is not the same as "beat" either.

<>The fact that a question does not meet its presuppositions does not make it
>less of a question, it merely makes it one that has a peculiar correct
>answer.

One that has no correct logical answer, in my view. Correct
illocutionary answers it has aplenty, I agree.>

One of the reasons I prefer illocutionary answers.  It is the insistence on logical answers that gives these kinds of questions their force and they should be stripped of it.
--part1_2f.1bd84b72.28f39658_boundary--