From a.rosta@lycos.co.uk Wed Nov 06 17:57:59 2002
Return-Path: <lojban-out@lojban.org>
X-Sender: lojban-out@lojban.org
X-Apparently-To: lojban@yahoogroups.com
Received: (EGP: mail-8_2_3_0); 7 Nov 2002 01:57:59 -0000
Received: (qmail 90780 invoked from network); 7 Nov 2002 01:57:59 -0000
Received: from unknown (66.218.66.218)
  by m3.grp.scd.yahoo.com with QMQP; 7 Nov 2002 01:57:59 -0000
Received: from unknown (HELO digitalkingdom.org) (204.152.186.175)
  by mta3.grp.scd.yahoo.com with SMTP; 7 Nov 2002 01:57:59 -0000
Received: from lojban-out by digitalkingdom.org with local (Exim 4.05)
  id 189bvi-00008f-00
  for lojban@yahoogroups.com; Wed, 06 Nov 2002 17:57:58 -0800
Received: from digitalkingdom.org ([204.152.186.175] helo=chain)
  by digitalkingdom.org with esmtp (Exim 4.05)
  id 189bvd-000087-00; Wed, 06 Nov 2002 17:57:53 -0800
Received: with ECARTIS (v1.0.0; list lojban-list); Wed, 06 Nov 2002 17:57:52 -0800 (PST)
Received: from mrin02.spray.se ([212.78.193.8] helo=mrin02.st1.spray.net)
  by digitalkingdom.org with esmtp (Exim 4.05)
  id 189bvW-00007S-00
  for lojban-list@lojban.org; Wed, 06 Nov 2002 17:57:47 -0800
Received: from lmin04.st1.spray.net (lmin04.st1.spray.net [212.78.202.104])
  by mrin02.st1.spray.net (Postfix) with ESMTP id 89195248683
  for <lojban-list@lojban.org>; Thu, 7 Nov 2002 02:57:14 +0100 (CET)
Received: from oemcomputer (host213-121-66-176.surfport24.v21.co.uk [213.121.66.176])
  by lmin04.st1.spray.net (Postfix) with ESMTP id 2F6911C155
  for <lojban-list@lojban.org>; Thu, 7 Nov 2002 02:57:13 +0100 (MET)
To: <lojban-list@lojban.org>
Subject: [lojban] Re: importing ro
Date: Thu, 7 Nov 2002 01:59:00 -0000
Message-ID: <LPBBJKMNINKHACNDIIGMIEFHGNAA.a.rosta@lycos.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <3DC92B49.9060908@newmail.net>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
X-archive-position: 2477
X-ecartis-version: Ecartis v1.0.0
Sender: lojban-list-bounce@lojban.org
Errors-to: lojban-list-bounce@lojban.org
X-original-sender: a.rosta@lycos.co.uk
Precedence: bulk
X-list: lojban-list
From: "And Rosta" <a.rosta@lycos.co.uk>
Reply-To: a.rosta@lycos.co.uk
X-Yahoo-Group-Post: member; u=122260811
X-Yahoo-Profile: andjamin

Adam:
> la .and. cusku di'e
> 
> > The book is quite clear that ro as a quantifier is importing (16.8,
> > as pc has just pointed out on Jboske). Like you, my preference
> > would have been for nonimporting ro, but I can't see any grounds
> > for overriding the book -- it's not inconsistent or 'broken' on
> > this point. 
> 
> It sure is inconsistent on this point. According to the book, 'ro 
> pavyseljirna xirma cu blabi' is false, since 'ro pavyseljirna' has 
> existential import, and thus 'naku ro pavyseljirna xirma cu blabi' is 
> true, since it is the negation of a false statement. According to ch. 16 
> sec. 11, this is exactly equivalent to 'su'o pavyseljirna xirma naku 
> blabi', which is false, since once again it claims existence of 
> unicorns, and so either the book allows contradictions, and should be 
> called 'the complete zenban language', or we can disregard that 
> silliness about 'ro' having existential import, and use 'ro' as is 
> standard in mathematics at least (whether or not that is the standard 
> use in logic, as pc seems very certain that it is not) 

As far as I can see, then, the book is contradictory (for entirely
pardonable reasons!). So we have two choices.

Q1. Does {(ro) da poi broda} entail {da broda}?
Q2. Is {na ku ro broda cu broda} equivalent to {su'o broda cu na ku 
brode}?

Option A Option B
Q1 NO YES
Q2 YES NO

Either choice is defensible, but like you and xorxes I vastly prefer
Option A. I can't see any practical advantages to Option B. pc,
the main instigator and advocate of the Yes answer to Q1, bases
his reasons on the way things work in logic, but we do not have
to agree that {da poi} is restricted quantification; we can decree
that it is not. Anybody who really wants restricted quantification
and Option B can create appropriate experimental cmavo for it.

It seems to me that we can do no more than put it to a vote.
The only grounds for choosing between the two options is by
the criterion of which one we find the more useful and convenient.


--And.




