From pycyn@aol.com Fri Sep 07 01:32:42 2001 Return-Path: X-Sender: Pycyn@aol.com X-Apparently-To: lojban@yahoogroups.com Received: (EGP: mail-7_3_2_1); 7 Sep 2001 08:32:42 -0000 Received: (qmail 17084 invoked from network); 7 Sep 2001 08:32:41 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 7 Sep 2001 08:32:41 -0000 Received: from unknown (HELO imo-r06.mx.aol.com) (152.163.225.102) by mta1 with SMTP; 7 Sep 2001 08:32:41 -0000 Received: from Pycyn@aol.com by imo-r06.mx.aol.com (mail_out_v31_r1.4.) id r.65.1a5ae341 (4012) for ; Fri, 7 Sep 2001 04:32:39 -0400 (EDT) Message-ID: <65.1a5ae341.28c9e027@aol.com> Date: Fri, 7 Sep 2001 04:32:39 EDT Subject: Re: [lojban] Another stab at a Record on ce'u To: lojban@yahoogroups.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_65.1a5ae341.28c9e027_boundary" X-Mailer: AOL 6.0 for Windows US sub 10535 From: pycyn@aol.com X-Yahoo-Message-Num: 10515 --part1_65.1a5ae341.28c9e027_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 9/6/2001 8:00:54 PM Central Daylight Time, a.rosta@dtn.ntl.com writes: > But I think we also agreed that these rules aren't worth the trouble, > so there's no point answering my objections unless you do believe your > proposal to still be worth discussing. > Well, worth is hard to determine, but I think the best rule is simply to put in all the ones you really mean to use. I can demonstrate the efficiency of the alternate version, but not the practicality of using it, so drop it. And rewite the earlier stuff to the new standard, as far as possible, I think. --part1_65.1a5ae341.28c9e027_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 9/6/2001 8:00:54 PM Central Daylight Time,
a.rosta@dtn.ntl.com writes:


But I think we also agreed that these rules aren't worth the trouble,
so there's no point answering my objections unless you do believe your
proposal to still be worth discussing.


Well, worth is hard to determine, but I think the best rule is simply to put
in all the ones you really mean to use.  I can demonstrate the efficiency of
the alternate version, but not the practicality of using it, so drop it.  And
rewite the earlier stuff to the new standard, as far as possible, I think. --part1_65.1a5ae341.28c9e027_boundary--