[YG Conlang Archives] > [jboske group] > messages [Date Index] [Thread Index] >
Jordan:
> On Sun, Dec 15, 2002 at 02:27:58PM -0000, And Rosta wrote:
> > Jordan:
> > > On Sat, Dec 14, 2002 at 11:07:16PM -0000, And Rosta wrote:
> [...]
> > > > The convenience of ke'a is exactly when you want to use one variable
> > > > more than once. It saves having to use ce'u subscripting (also an
> > > > unofficial convention), or nei/no'a subscripting (also unofficial),
> > > > which also won't even work if neither instance of the variable is
> > > > an argument of the selbri. The method that definitely will work is
> > > > ko'a-assignment with goi, but that is cumbersome. So, ke'a is much
> > > > more convenient than the alternatives
> > >
> > > Ok; you ignored the main point though: people almost *never* need
> > > to repeat these things in practice
> >
> > None of us have very much basis for judging this, seeing as we have
> > all of us written and read so little, but you have had more
> > experience than me. All the same, in what I have read and written
> > I have noticed that other people are generally happy to use anaphora
> > that relies on glorking, while I am not and consequently find the
> > problem to be a severe one. (It's not that I think glorking is bad,
> > but the very thing that attracts me to a logical language is the
> > extent to which it can feasibly reduce reliance on glorking.)
>
> Ok I can just tell you, that I see ka stuff a lot, and probably 1
> in 100 (or less) have more than one ce'u in it. You can take my
> word for this (I have about a conversation a day in lojban on irc)
> or not
But at no point was I talking about ka with multiple ce'u. I
was talking about a bridi containing two sumti (not necessarily
sumti of the same selbri) that are intended to be interpreted as
coreferential.
My own intuitions do tell me that ka with multiple ce'u will be
rare. But they tell me that coreferential sumti will be frequent.
> Anyway; I don't find "goi ko'a" particularly difficult. I would
> use ce'uxipa though
Think about how your usage and others' handles coreference, and
how much of it requires no glorking. Or, as an exercise, try
writing in a way such that coreference is handled in a glorking-
free way. I'd be interested to see the results and to see whether
you are happy with the mechanisms Lojban provides.
It is not that "goi ko'a" is horrendously difficult, but are you
happy to use it every time you introduce a new referent in a
text or a paragraph or a sentence?
> > > WRT to subscripting; those are obvious and (afaik) uncontroversial
> > > conventions which may very well be standard in a while
> >
> > Is your subscripting scheme on the wiki? I remember us discussing
> > subscripting schemes (for nei/no'a) on one of the lists a while
> > back and not reaching agreement on the details of the scheme or
> > on what counts as a bridi (though iirc it was pc who disagreed
> > with others about what counts as a bridi, so maybe that disagreement
> > can be considered defunct)
>
> I was speaking of ce'u. Subscripting on nei is probably useless,
> since you can just script no'a (which *is* book specified I think)
There was no call for subscripting of ce'u previously, but I agree
that your unofficial proposal is straightforward.
Whether it is nei or no'a that is subscripted, one will want a way
to count inwards from the root bridi and outwards from the local
bridi. Even then it won't help for antecedents embedded within
sumti.
> > > > That said, if there are poi/poi'i embedded within poi/poi'i, ko'a
> > > > assignment remains necessary, which is what led me to propose a
> > > > range of experimentals to abbreviate KOhA-assignment
> > >
> > > Most of those abbreviation things are a bit of a joke though. You
> > > have things like "goi'a" IIRC, which saves *one* syllable, and needs
> > > preprocessor changes to work properly.
> >
> > If any require preprocessor changes then that was inadvertent error
> > on my part, as I have striven to distinguish between what is and
> > isn't baseline-compliant. (Preprocessor changes obviously aren't
> > baseline-compliant.) I will check "goi'a" when I go online; my
> > recollection was that I had proposed such a thing but moved it to
> > the page for obsolete proposals, but I may have intended to move
> > it but forgotten to actually do it
>
> It would've required processor changes to do it right. Putting it
> into KU is a hack
You have some notion of an aesthetic for the grammar of Lojban that
I am not aware of. I of course have a powerful aesthetic sensibility,
but it evidently doesn't coincide with yours.
> > Because the scope for introducing glork-free anaphora is so limited,
> > because of tight constraints on innovation, it is inevitable that
> > experimental cmavo can ameliorate the problem to only a slight
> > degree
>
> I'm not sure what the problem is?
The problem of wanting to say explicitly what one means without relying
on glorking. If you don't have the urge to avoid glorking, then you
just need to accept that the urge to avoid glorking is a valid reason
to be interested in a logical language and is a reason for wanting
good ways to do glork-free anaphora.
> > Regarding the saving of a single syllable, there is a sense in
> > which the saving of words is desirable, regardless of whether it
> > saves syllables. There are two reasons for this. The first is that
> > since syllable-count was ignored in the design, the best way to
> > do justice to the design, when exploring it through usage, is to
> > ignore syllable-count. The second reason is that one can measure
> > length not only in syllables but also in words (which are the units
> > of input that the parser operates on)
>
> I highly disagree. Unless there are stops between the words for
> some reason it doesn't count. I see no benifit to being shorter
> in terms of words (esp. since a lot of words can get compounded
> together also ("goiko'a", "lenu"). And having a relatively hackish
> shorting cmavo just to save *one* syllable is pretty laughable
You disagree, but you haven't argued against my reasons, so I note
that you disagree, but see no reason to change my mind.
> > > Furthermore, the entire idea
> > > of proposing them now before there's any usage (particularly usage
> > > by yourself) suggesting them warranted goes against what you were
> > > saying about your views on shortings on the main list
> >
> > If we had as a community agreed on a programme of usage that would
> > explore the design and deliberately ignore syllable count and, to
> > a certain extent, word count (e.g. allowing us to compound cmavo
> > that we wish were a single word, and letting the compound count as
> > a single word by stylistic criteria), then I would not be proposing
> > these abbreviatory experimentals. The one thing is what I think
> > the community should do, and the other thing is what I do given
> > what the community thinks it should do
> [...]
>
> I don't think any such thing is needed. If shortings are to be
> properly done, they should be done after there's *at least* 40-50
> fluent speakers and it should be done by frequency counts of text
> with the intent being to convert the most common 5-6 syllable strings
> into 1-2 syllables (and this only if the most common 5-6 syl. string
> is common enough for this to work). Doing it by what we *think*
> is going to be useful is a bad idea
I think you didn't understand what I said. What *should* be done
is to promote a policy of usage that deliberately strives to ignore
length/conciseness issues in certain respects, and then after, say, a
million words of fully competent text has been generated, the sort
of compression methods that you mention can be computed. However,
the creation of an unbiased/level playing field in usage is
definitely not going to happen, and the compression baseline change
is unlikely to happen.
Instead, the only method available is the method Lojban standardly
uses, which is to make options available, and let users choose their
preferred options. Time will then tell which options were found
useful and which useless. (At least, that was the hope, though as
discussed in other messages, I think normativity conspires against
it.)
--And.