From pycyn@aol.com Tue Mar 12 14:27:04 2002
Return-Path: <Pycyn@aol.com>
X-Sender: Pycyn@aol.com
X-Apparently-To: lojban@yahoogroups.com
Received: (EGP: unknown); 12 Mar 2002 22:27:03 -0000
Received: (qmail 71187 invoked from network); 12 Mar 2002 22:27:03 -0000
Received: from unknown (216.115.97.172)
  by m9.grp.snv.yahoo.com with QMQP; 12 Mar 2002 22:27:03 -0000
Received: from unknown (HELO imo-d09.mx.aol.com) (205.188.157.41)
  by mta2.grp.snv.yahoo.com with SMTP; 12 Mar 2002 22:27:03 -0000
Received: from Pycyn@aol.com
  by imo-d09.mx.aol.com (mail_out_v32.5.) id r.3c.1ab7d0bf (3996)
  for <lojban@yahoogroups.com>; Tue, 12 Mar 2002 17:26:58 -0500 (EST)
Message-ID: <3c.1ab7d0bf.29bfdab1@aol.com>
Date: Tue, 12 Mar 2002 17:26:57 EST
Subject: Re: [lojban] More about quantifiers
To: lojban@yahoogroups.com
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="part1_3c.1ab7d0bf.29bfdab1_boundary"
X-Mailer: AOL 7.0 for Windows US sub 118
From: pycyn@aol.com
X-Yahoo-Group-Post: member; u=2455001
X-Yahoo-Profile: kaliputra

--part1_3c.1ab7d0bf.29bfdab1_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

In a message dated 3/12/2002 2:56:35 PM Central Standard Time, 
arosta@uclan.ac.uk writes:


> The syntax of Lojban is such that every "lo" sumti can be 
> translated into a "da poi ... ke'a" sumti, but not vice versa. 
> (The main examples would be where ke'a is embedded 
> within a subordinate bridi or sumti within the relative
> clause.) 
> 
> Hence, any 'exchange' between the two must be one-way, from
> "da poi ke'a" to "lo". 
> 
> Hence it makes sense to see "lo" as simply an abbreviation
> of "da poi ke'a".
> 

Well, I think this is probably due to lack of ingenuity on somebodies part, 
but since I share that with them, i.e., have no clue how to do it in extreme 
cases, I'll take that as a defect. Not much of one, of course, since I 
really do want to have {da poi} on the importing side but I was following 
Cowan's example and the advice of improbability in ttrying to ndail down the 
different forms. Also, it seems to leave only the ultimate forms or something 
very like them for the free forms and that is probably too yucky to mention 
(maybe that was what the advice about not getting {da poi} as + meant).

<Further, if Jorge and pc want to propose comprehensive
systems for importing and nonimporting quantifiers, they
should be done solely on the basis of "da poi ke'a", since
only such a system will generalize to all cases. In this
respect, Jorge's and pc's proposals are equally defective.>

How disappointing! But it does provide a nice agreeable ending for the 
discussion. Except that we now have no forms for the people who seem to want 
- forms. Not a great loss, I think, but they (and I rather think & and 
surely xorxes are in the group) will want to protest. Well, let them come up 
with a good answer, then.


--part1_3c.1ab7d0bf.29bfdab1_boundary
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

<HTML><FONT FACE=arial,helvetica><BODY BGCOLOR="#ffffff"><FONT style="BACKGROUND-COLOR: #ffffff" SIZE=2>In a message dated 3/12/2002 2:56:35 PM Central Standard Time, arosta@uclan.ac.uk writes:<BR>
<BR>
<BR>
<BLOCKQUOTE TYPE=CITE style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">The syntax of Lojban is such that every "lo" sumti can be <BR>
translated into a "da poi ... ke'a" sumti, but not vice versa. <BR>
(The main examples would be where ke'a is embedded <BR>
within a subordinate bridi or sumti within the relative<BR>
clause.) <BR>
<BR>
Hence, any 'exchange' between the two must be one-way, from<BR>
"da poi ke'a" to "lo". <BR>
<BR>
Hence it makes sense to see "lo" as simply an abbreviation<BR>
of "da poi ke'a".<BR>
</BLOCKQUOTE><BR>
<BR>
Well, I think this is probably due to lack of ingenuity on somebodies part, but since I share that with them, i.e., have no clue how to do it in extreme cases, I'll take that as a defect.&nbsp; Not much of one, of course, since I really do want to have {da poi} on the importing side but I was following Cowan's example and the advice of improbability in ttrying to ndail down the different forms. Also, it seems to leave only the ultimate forms or something very like them for the free forms and that is probably too yucky to mention (maybe that was what the advice about not getting {da poi} as + meant).<BR>
<BR>
&lt;Further, if Jorge and pc want to propose comprehensive<BR>
systems for importing and nonimporting quantifiers, they<BR>
should be done solely on the basis of "da poi ke'a", since<BR>
only such a system will generalize to all cases. In this<BR>
respect, Jorge's and pc's proposals are equally defective.&gt;<BR>
<BR>
How disappointing!&nbsp; But it does provide a nice agreeable ending for the discussion.&nbsp; Except that we now have no forms for the people who seem to want - forms.&nbsp; Not a great loss, I think, but they (and I rather think &amp; and surely xorxes are in the group) will want to protest.&nbsp; Well, let them come up with a good answer, then.<BR>
<BR>
</FONT></HTML>
--part1_3c.1ab7d0bf.29bfdab1_boundary--

