From pycyn@aol.com Fri Apr 13 07:27:56 2001
Return-Path: <Pycyn@aol.com>
X-Sender: Pycyn@aol.com
X-Apparently-To: lojban@yahoogroups.com
Received: (EGP: mail-7_1_2); 13 Apr 2001 14:27:56 -0000
Received: (qmail 20651 invoked from network); 13 Apr 2001 14:27:55 -0000
Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 13 Apr 2001 14:27:55 -0000
Received: from unknown (HELO imo-m10.mx.aol.com) (64.12.136.165) by mta2 with SMTP; 13 Apr 2001 14:27:55 -0000
Received: from Pycyn@aol.com by imo-m10.mx.aol.com (mail_out_v29.14.) id r.b4.1416aa5a (4321) for <lojban@yahoogroups.com>; Fri, 13 Apr 2001 10:27:37 -0400 (EDT)
Message-ID: <b4.1416aa5a.280866d8@aol.com>
Date: Fri, 13 Apr 2001 10:27:36 EDT
Subject: Re: [lojban] Re: FA tagging
To: lojban@yahoogroups.com
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="part1_b4.1416aa5a.280866d8_boundary"
Content-Disposition: Inline
X-Mailer: AOL 6.0 for Windows US sub 10519
From: pycyn@aol.com

--part1_b4.1416aa5a.280866d8_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

In a message dated 4/13/2001 5:05:37 AM Central Daylight Time, 
Ti@fa-kuan.muc.de writes:


> My conclusion from this still is: It is not explicitely disallowed to force 
> a sumti out of its (non-tagged!) place by a FA tagged sumti 
> (coming afterwards) claiming this place, unless that sumti coming first 
> claims its place by the same tag (which then causes the 
> competing sumtis to share the place).
> 
Yes, that is a *possible* reading, but not one that is likely to carry the 
day, since it requires reassigning a sumti to a place after the fact, 
something we have hesitated to do on other occasions (negations are about the 
only significant piece we can mess around with that way and they are such 
high level items that they don't require a lot of internal reworking). 
Imagine working out a whole sentence, then finding a {fa} tag and having to 
shift every sumti one place right and reconstrue! My own personal preference 
is to disallow tags for places already taken, that is to anticipate places 
but not to delay them, unless another tag has apppeared to skip over the 
later place. I don't think that can be a grammar rule without a lot of 
problems, but it sure is a stylistic one I'd come down heavy for.






--part1_b4.1416aa5a.280866d8_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 4/13/2001 5:05:37 AM Central Daylight Time, 
<BR>Ti@fa-kuan.muc.de writes:
<BR>
<BR>
<BR><BLOCKQUOTE TYPE=CITE style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">My conclusion from this still is: It is not explicitely disallowed to force 
<BR>a sumti out of its (non-tagged!) place by a FA tagged sumti 
<BR>(coming afterwards) claiming this place, unless that sumti coming first 
<BR>claims its place by the same tag (which then causes the 
<BR>competing sumtis to share the place).
<BR></BLOCKQUOTE>
<BR>Yes, that is a *possible* reading, but not one that is likely to carry the 
<BR>day, since it requires reassigning a sumti to a place after the fact, 
<BR>something we have hesitated to do on other occasions (negations are about the 
<BR>only significant piece we can mess around with that way and they are such 
<BR>high level items that they don't require a lot of internal reworking). &nbsp;
<BR>Imagine working out a whole sentence, then finding a {fa} tag and having to 
<BR>shift every sumti one place right and reconstrue! &nbsp;My own personal preference 
<BR>is to disallow tags for places already taken, that is to anticipate places 
<BR>but not to delay them, unless another tag has apppeared to skip over the 
<BR>later place. &nbsp;I don't think that can be a grammar rule without a lot of 
<BR>problems, but it sure is a stylistic one I'd come down heavy for.
<BR>
<BR>
<BR>
<BR>
<BR></FONT></HTML>

--part1_b4.1416aa5a.280866d8_boundary--

