From pycyn@aol.com Wed Nov 06 13:40:30 2002
Return-Path: <Pycyn@aol.com>
X-Sender: Pycyn@aol.com
X-Apparently-To: lojban@yahoogroups.com
Received: (EGP: mail-8_2_3_0); 6 Nov 2002 21:40:30 -0000
Received: (qmail 68842 invoked from network); 6 Nov 2002 21:40:29 -0000
Received: from unknown (66.218.66.218)
  by m15.grp.scd.yahoo.com with QMQP; 6 Nov 2002 21:40:29 -0000
Received: from unknown (HELO imo-d06.mx.aol.com) (205.188.157.38)
  by mta3.grp.scd.yahoo.com with SMTP; 6 Nov 2002 21:40:29 -0000
Received: from Pycyn@aol.com
  by imo-d06.mx.aol.com (mail_out_v34.13.) id r.122.1a0db154 (4539)
  for <lojban@yahoogroups.com>; Wed, 6 Nov 2002 16:40:26 -0500 (EST)
Message-ID: <122.1a0db154.2afae64a@aol.com>
Date: Wed, 6 Nov 2002 16:40:26 EST
Subject: Re: [lojban] Re: importing ro
To: lojban@yahoogroups.com
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="part1_122.1a0db154.2afae64a_boundary"
X-Mailer: AOL 8.0 for Windows US sub 230
From: pycyn@aol.com
X-Yahoo-Group-Post: member; u=2455001
X-Yahoo-Profile: kaliputra

--part1_122.1a0db154.2afae64a_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

In a message dated 11/6/2002 12:23:23 PM Central Standard Time, 
araizen@newmail.net writes:
<<
> >It should be noted, btw, that:
> >
> > no pavyseljirna cu blabi
> >
> >is a false statement because no imports also, since it can be moved
> >around.
> 
> If it is indeed false, then either 'su'o pavyseljirna' is not importing 
> (probably not the best option), or 'no pavyseljirna' != 'naku su'o 
> pavyseljirna', which is extremely counterintuitive, no matter how 
> intuitive an importing ro might be
>>
I think it is true and {no broda} does not import for broda. That is 
certainly the simplest way to do it -- provided {mi'ero broda} does also not 
import for broda. But, of course, this means going beyond -- and soimetimes 
against -- what CLL says about negation movement and the like. But, given 
that that was written in oblivion of the second system (not really, but let's 
leave that for now), it seems appropriate to correct it at this time (again). 



--part1_122.1a0db154.2afae64a_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 FAMILY="SANSSERIF" FACE="Arial" LANG="0">In a message dated 11/6/2002 12:23:23 PM Central Standard Time, araizen@newmail.net writes:<BR>
&lt;&lt;<BR>
<BLOCKQUOTE TYPE=CITE style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">&gt;It should be noted, btw, that:<BR>
&gt;<BR>
&gt;&nbsp; no pavyseljirna cu blabi<BR>
&gt;<BR>
&gt;is a false statement because no imports also, since it can be moved<BR>
&gt;around.<BR>
<BR>
If it is indeed false, then either 'su'o pavyseljirna' is not importing <BR>
(probably not the best option), or 'no pavyseljirna' != 'naku su'o <BR>
pavyseljirna', which is extremely counterintuitive, no matter how <BR>
intuitive an importing ro might be</BLOCKQUOTE></FONT><FONT COLOR="#000000" style="BACKGROUND-COLOR: #ffffff" SIZE=2 FAMILY="SANSSERIF" FACE="Arial" LANG="0"><BR>
&gt;&gt;<BR>
I think it is true and {no broda} does not import for broda</FONT><FONT COLOR="#000000" style="BACKGROUND-COLOR: #ffffff" SIZE=2 FAMILY="SANSSERIF" FACE="Arial" LANG="0">. That is certainly the simplest way to do it -- provided {mi'ero broda} does also not import for broda. But, of course, this means going beyond -- and soimetimes against -- what CLL says about negation movement and the like.&nbsp; But, given that that was written in oblivion of the second system (not really, but let's leave that for now), it seems appropriate to correct it at this time (again). </FONT><FONT COLOR="#000000" style="BACKGROUND-COLOR: #ffffff" SIZE=2 FAMILY="SANSSERIF" FACE="Arial" LANG="0"><BR>
</FONT><FONT COLOR="#000000" style="BACKGROUND-COLOR: #ffffff" SIZE=2 FAMILY="SANSSERIF" FACE="Arial" LANG="0"><BR>
</FONT></HTML>
--part1_122.1a0db154.2afae64a_boundary--

