RE: [lojban] Re: Why we should cancel the vote or all vote NO (was RE: Official Statement- LLG Board approves new baseline policy

["And Rosta" <a.rosta@lycos.co.uk>]

Jordan:
> 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
> Jordan is
> > > > too) that mex and other stuff that has never seen substantial usage be
> > > > made more longwinded so that future generations of fluent lojbanists can
> > > > decide where shortwindedness can most efficaciously be applied
> > >
> > > 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
> >
> > How does the new-assignments-without-revoking-old work?
>
> 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

There might be a fair bit of support. I know xorxes and Adam have
had the knives out for lau. Only Lojbab is positively fond of lau,
afaik. The rest of the opposition is just general antitinkering.

> > > [...]
> > > > > >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-maintained
> > > > > >mahoste that can be updated with cmavo not listed in the
> mini-dictionary
> > > > >
> > > > > Then write one
> > > >
> > > > 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
> > >
> > > Erm.  Lojbab was suggesting you write that parser.  ;P
> >
> > 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

I understand now. In saying that the parser should take input from
the mahoste I did not mean "somebody should go and do the work of
modifying the existing parser". I meant "conceptually, the right
way for a parser to work is for it to take input from a mahoste".
That wasn't a complaint.

--And.