Subject: RE: [lojban] Re: Mark on wiki on lerfu

From: "And Rosta" <[email-masked]>
Date: Sat, 8 Sep 2001 18:37:19 +0100

Mark:
> --- In lojban@y..., "And Rosta" <a.rosta@n...> wrote:
> > Mark writes
> (http://nuzban.wiw.org/wiki/index.php?Type%204%20fu%27ivla):
> > 
> > "we can use any string of lerfu as a ko'a-style sumti variable
> (which makes me
> > think that there's practically no reason ever to use the ko'a series
> at all)"
> > 
> > -- can you explain?
> 
> Um, I can try.
> 
> As I understand it, any old lerfu-string in a sentence can be used as
> a sumti (yes, it's also a mex, usable with li, and so forth. I mean
> just a bare string of lerfu as a sumti). It's considered a "variable"
> pro-sumti, assignable with goi (well, you can assign any sumti with
> goi, but I mean it's semantically and pragmatically sensible in
> general with lerfu-strings). If unassigned, they default to the most
> recent sumti with the appropriate initial letter(s), if any, or so
> they tell me. 

Ah. I hadn't realized they were assignable. How do you tell whether
a sequence of two lerfu is one lerfu string (one sumti) or a sequence 
of two lerfu strings (two sumti)?

> So I can say "le ctuca .e le vecnu cu prami le speni be
> cy." for "the teacher and the merchant [separately] love the spouse of
> the teacher," relying on the default that "cy." goes back to "ctuca." 
> Or, more conservatively, you can say "le ctuca goi cy. .e le vecnu..."
> with the same result, using cy. exactly like ko'a (with the slight
> difference that an unassigned ko'a is meaningless, 

This is debatable. I'm of the view that unassigned ko'a = "it" = "le du".
So "ko'a klama" = "it goes, a certain thing goes"; "ko'a ge pendo be mi
gi klama" = "a certain friend of mine goes".

> while an unassigned
> lerfu-string will at least TRY to find a meaning, possibly the one you
> wanted). So basically, a lerfu-string can do anything a ko'a can do,
> and then some. The two and-then-somes are: (a) as mentioned, if it's
> unassigned, it will try to snag a nearby meaning, and if done
> properly, this is not so bad and pretty reliable (see below). (b)
> lerfu-strings have far more potential for mnemonic power than ko'a. 

This is what attracted my notice. I'd proposed ko'au (or ko'ai -- I
forget which) for this reason.

> It's a lot easier to keep track of pronouns for la bab., la djan., la
> .alis., and la fred. as by., dy., .abu, and fy. than as ko'a, ko'e,
> ko'i, and ko'o (has ANYONE ever used ko'o? I had to look that one up
> to double-check that it really was still in the series).
> 
> I like using these, though I don't trust the implicit assignments
> completely (but I do use them, just not in all cases). The
> mnemonicity is a real brain-saver. I don't like the implicit
> assignment with descriptors, though, for some reason. Somehow it
> doesn't seem that reliable. Maybe it's because there's nothing about
> lo ctuca that particularly would associate her with cy; I might just
> as easily have described her as lo ninmu and use ny. This is not a
> valid argument I'm making, just something that sort of affects my
> thinking (after all, there are endlessly many names for everyone). 
> Also, with all the brivla that get used in a sentence, I could easily
> forget that there was another intervening cy-sumti that would thus get
> misassigned. But with names I have no such qualms, especially if I
> have a two-word name and can use two initials. This saves me the
> assignment step, and works quite well. So in
> http://www.kli.org/kli/langs/KLIlojban.html I refer to "la mark.
> okrand." and then in the next sentence use "my.obu." Perhaps that's
> counting on a little too much, that the reader should know I'm taking
> initials (as opposed to, say, the first two letters in the name), I
> don't know. I think it works. Or recently I was writing something
> about the Phillip Morris company, referring to it as "la filip moris"
> and then as "fy.my." (or "fymy.") 

might "fymy" be one sumti and "fy my" two?

> On the other hand, when I
> introduced the KLI as "la klingon. zei bangu ckule", I assigned it
> with "goi kybycy." and used that throughout (I didn't trust the
> assignment to a tanru/lujvo/zei-thingy of indeterminate initials). 
> Multi-letter strings are even less prone to confusion than single
> letters, so I think they work quite well. I used "xy." for the KLI's
> journal HolQeD, but assigned it with goi, since I used la'o quotes and
> can't count on people to know the pronunciation.
> 
> (As an aside, here's a bizarre consequence... since cmene+bu is
> syntactically a lerfu, you could use ".mark.bu" as a sumti, leaving it
> up to the listener to somehow work out who it was... which isn't all
> that much worse than saying "la mark." and hoping they know. 

Ooh, this is ingenious!

> The best
> guess for "mark.bu" is probably somebody named Mar[ck], right? (And no
> cracks about how "mark.bu" is some "letter Mark." That's true, when
> *mentioned*, but not when used this way. "li mark.bu" is a
> mathematical expression, like using "area" as a variable. To get
> "letter-mark" you'd need a letter context, not a sumti context. Just
> like I can use "by." for la bab., I can use "mark.bu" for la
> markonilentironafilos.))
>
> The only advantage ko'a-series does still have (aside from history) is
> the fact that three of the fo'a series (fo'a, fo'e, fo'i) have rafsi
> and can thus make lujvo... but has anyone really done this? 

and what on earth could it mean?

> So that's
> why I say I think the ko'a-series doesn't have much utility. Anything
> they can do, lerfu-strings can, and more, and easier.
> 
> Nick just sent me (at long last) comments on the KLI info page in
> Lojban, so I'll probably be making some edits in it soon. Look at it
> anyway; I'm pretty proud of it, mistakes and all.
> 
> And, should this rant go on the Wiki?

Oh yes, defo. Probably under [Proposed interpretive conventions] would
be the best place. But clear up my one sumti/two sumti question first.

--And.

ps Oh sorry -- I see you answered that question in a later message. That
boi's a bit of a downer to your proposals, isn't it.