From lojban-out@lojban.org Mon Dec 02 18:00:48 2002 Return-Path: X-Sender: lojban-out@lojban.org X-Apparently-To: lojban@yahoogroups.com Received: (EGP: mail-8_2_3_0); 3 Dec 2002 02:00:48 -0000 Received: (qmail 81100 invoked from network); 3 Dec 2002 02:00:48 -0000 Received: from unknown (66.218.66.216) by m14.grp.scd.yahoo.com with QMQP; 3 Dec 2002 02:00:48 -0000 Received: from unknown (HELO digitalkingdom.org) (204.152.186.175) by mta1.grp.scd.yahoo.com with SMTP; 3 Dec 2002 02:00:48 -0000 Received: from lojban-out by digitalkingdom.org with local (Exim 4.05) id 18J2Mi-00040R-00 for lojban@yahoogroups.com; Mon, 02 Dec 2002 18:00:48 -0800 Received: from digitalkingdom.org ([204.152.186.175] helo=chain) by digitalkingdom.org with esmtp (Exim 4.05) id 18J2Md-000409-00; Mon, 02 Dec 2002 18:00:44 -0800 Received: with ECARTIS (v1.0.0; list lojban-list); Mon, 02 Dec 2002 18:00:42 -0800 (PST) Received: from cs6668125-184.austin.rr.com ([66.68.125.184] ident=root) by digitalkingdom.org with esmtp (Exim 4.05) id 18J2MY-0003zy-00 for lojban-list@lojban.org; Mon, 02 Dec 2002 18:00:39 -0800 Received: from cs6668125-184.austin.rr.com (asdf@localhost [127.0.0.1]) by cs6668125-184.austin.rr.com (8.12.3/8.12.3) with ESMTP id gB326WG9044034 for ; Mon, 2 Dec 2002 20:06:32 -0600 (CST) (envelope-from fracture@cs6668125-184.austin.rr.com) Received: (from fracture@localhost) by cs6668125-184.austin.rr.com (8.12.3/8.12.3/Submit) id gB326V5C044033 for lojban-list@lojban.org; Mon, 2 Dec 2002 20:06:31 -0600 (CST) Date: Mon, 2 Dec 2002 20:06:31 -0600 To: lojban-list@lojban.org Subject: [lojban] Re: Why we should cancel the vote or all vote NO (was RE: Official Statement- LLG Board approves new baseline policy Message-ID: <20021203020631.GB43563@allusion.net> References: <20021202162407.GA37047@allusion.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="i9LlY+UWpKt15+FH" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i X-archive-position: 2929 X-ecartis-version: Ecartis v1.0.0 Sender: lojban-list-bounce@lojban.org Errors-to: lojban-list-bounce@lojban.org X-original-sender: fracture@allusion.net Precedence: bulk X-list: lojban-list X-eGroups-From: Jordan DeLong From: Jordan DeLong Reply-To: fracture@allusion.net X-Yahoo-Group-Post: member; u=116389790 X-Yahoo-Profile: lojban_out X-Yahoo-Message-Num: 17420 --i9LlY+UWpKt15+FH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Dec 02, 2002 at 07:02:33PM -0000, And Rosta wrote: > Jordan: > > On Mon, Dec 02, 2002 at 11:04:47AM -0000, And Rosta wrote: > > > Avoiding making mex harder to use is not a good reason for not making= the > > > rest of the language easier to use. I am proposing (and I think Jorda= n is > > > too) that mex and other stuff that has never seen substantial usage b= e > > > made more longwinded so that future generations of fluent lojbanists = can > > > decide where shortwindedness can most efficaciously be applied=20 > >=20 > > I don't support touching any of mex (unless lau/tei is considered > > mex). I support And's *idea* here, but not the exact method by > > which he wants to implement it. I think it is sufficent to add new > > assignments for one or two 0-usage monosyllabic cmavo without > > revoking their own assignemnts, and to refrain from using monosyllabic > > xVV space=20 >=20 > How does the new-assignments-without-revoking-old work?=20 We assign lau'oi to selma'o LAU, with the exact meaning of lau. We assign tei'oi to selma'o TEI, with the exact meaning of tei. A statement is made that "lau'oi" and "tei'oi" should be used in stead of "lau" and "tei", because lau and tei may be reclaimed in the distant future for their monosyllabicness. However, since no one but me supports this more moderate approach to this, and the whole point would be to try to make both you and everyone else happy about future Zipf possibilites, I'm pretty much going to have to abandon it and go with everyone else in the view that we should not worry about Zipf at all. > > [...] > > > > >and instead > > > > >simply say that the mini-dictionary fixes the meaning of the cmavo= it > > > > >lists. A proper syntactic parser should not have the mahoste built > > > > >in to it, but should instead take input from a community-maintaine= d > > > > >mahoste that can be updated with cmavo not listed in the mini-dict= ionary > > > > > > > > Then write one > > >=20 > > > I have (collaboratively) written one for cmavo that are not in the > > > official mahoste. It is on the wiki. It is easily adaptable (with > > > about 1 minute's work) by anyone writing a parser to take input from > > > a mahoste=20 > >=20 > > Erm. Lojbab was suggesting you write that parser. ;P >=20 > Was he? I don't have the skills to write a parser, and I'm surprised > Lojbab thought I did. It was sarcasm. Anyway, you certainly could learn what you needed to know to write a parser (or rather to hook up to a yacc-generated parser---would be an interesting project to rewrite the grammar for LL(1) parsing though) if you felt like it. I find some interest in having a parser support querying the user (or perhaps a file in their home directory) for selma'o of bad cmavo (and this could probably be hacked onto the jbofi'e lexer without too much trouble). As Nick said, If you want something done, you probably have to do it yourself. If not, then you really shouldn't complain about what the current parsers support. --=20 Jordan DeLong - fracture@allusion.net lu zo'o loi censa bakni cu terzba le zaltapla poi xagrai li'u sei la mark. tuen. cusku --i9LlY+UWpKt15+FH Content-Type: application/pgp-signature Content-Disposition: inline [Attachment content not displayed.] --i9LlY+UWpKt15+FH--