From pycyn@aol.com Fri Sep 07 07:09:41 2001
Return-Path: <Pycyn@aol.com>
X-Sender: Pycyn@aol.com
X-Apparently-To: lojban@yahoogroups.com
Received: (EGP: mail-7_3_2_1); 7 Sep 2001 14:09:40 -0000
Received: (qmail 68060 invoked from network); 7 Sep 2001 14:05:17 -0000
Received: from unknown (10.1.10.142)
  by l9.egroups.com with QMQP; 7 Sep 2001 14:05:17 -0000
Received: from unknown (HELO imo-r05.mx.aol.com) (152.163.225.101)
  by mta3 with SMTP; 7 Sep 2001 14:05:14 -0000
Received: from Pycyn@aol.com
  by imo-r05.mx.aol.com (mail_out_v31_r1.4.) id r.f.1a63c50e (4327)
  for <lojban@yahoogroups.com>; Fri, 7 Sep 2001 10:05:05 -0400 (EDT)
Message-ID: <f.1a63c50e.28ca2e11@aol.com>
Date: Fri, 7 Sep 2001 10:05:05 EDT
Subject: Re: [lojban] li'i (was: Another stab at a Record on ce'u
To: lojban@yahoogroups.com
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="part1_f.1a63c50e.28ca2e11_boundary"
X-Mailer: AOL 6.0 for Windows US sub 10535
From: pycyn@aol.com

--part1_f.1a63c50e.28ca2e11_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

In a message dated 9/6/2001 8:00:14 PM Central Daylight Time, 
a.rosta@dtn.ntl.com writes:


> When others want to say {X se li'i ce'u broda}, I want it to be {X se li'i
> X broda}. In the most generalizable solution, the second X would be an
> anaphor whose antecedent/binder is the first X, the experiencer. I couldn't
> find any anaphor that would do the job, so proposed {no'au}, which works
> like no'a but applies to all types of phrase, not just bridi.
> 
Now, can X have an experience of brodaing in general, not of something 
brodaing. I guess I don't think so and so find {li'i ce'u broda} not to make 
sense. Must that something be X? Clearly not, but that is an especially 
common case, I would think. So the first temptation is surely to leave the 
first place of {broda} bare in that case -- and this is almost certainly what 
happened in the little bit of use {li'i} has gotten over the years. Popping 
that up the {ce'u}, on the analogy of {ka}, or to {zo'e}, on the analogy of 
{du'u}, seem equally misguided. Being explicit is, we now know from the 
toehr cases, the best policy, so we need "X" there or its anaphor. Would 
{ri} worik in most cases? Creating a new class of this situation (are there 
going to be others?) seems excessive. 


--part1_f.1a63c50e.28ca2e11_boundary
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

<HTML><FONT FACE=arial,helvetica><BODY BGCOLOR="#ffffff"><FONT SIZE=2>In a message dated 9/6/2001 8:00:14 PM Central Daylight Time, 
<BR>a.rosta@dtn.ntl.com writes:
<BR>
<BR>
<BR><BLOCKQUOTE TYPE=CITE style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">When others want to say {X se li'i ce'u broda}, I want it to be {X se li'i
<BR>X broda}. In the most generalizable solution, the second X would be an
<BR>anaphor whose antecedent/binder is the first X, the experiencer. I couldn't
<BR>find any anaphor that would do the job, so proposed {no'au}, which works
<BR>like no'a but applies to all types of phrase, not just bridi.
<BR></BLOCKQUOTE></FONT><FONT COLOR="#000000" SIZE=3 FAMILY="SANSSERIF" FACE="Arial" LANG="0">
<BR>Now, can X have an experience of brodaing in general, not of something 
<BR>brodaing. &nbsp;I guess I don't think so and so find {li'i ce'u broda} not to make 
<BR>sense. Must that something be X? &nbsp;Clearly not, but that is an especially 
<BR>common case, I would think. &nbsp;So the first temptation is surely to leave the 
<BR>first place of {broda} bare in that case -- and this is almost certainly what 
<BR>happened in the little bit of use {li'i} has gotten over the years. &nbsp;Popping 
<BR>that up the {ce'u}, on the analogy of {ka}, or to {zo'e}, on the analogy of 
<BR>{du'u}, seem equally misguided. &nbsp;Being explicit is, we now know from the 
<BR>toehr cases, the best policy, so we need "X" there or its anaphor. &nbsp;Would 
<BR>{ri} worik in most cases? &nbsp;Creating a new class of this situation (are there 
<BR>going to be others?) seems excessive. 
<BR></FONT></HTML>

--part1_f.1a63c50e.28ca2e11_boundary--

