WikiDiscuss

---

> My version of the algorithm (and I still haven't made a proper regression
> test) doesn't allow {critata} or {skalduna} to be used as a rafsi fu'ivla
> anywhere. As I understand xorxes' version, {critata} can be used only in
> final position and {skalduna} can be used only medially and finally, but I
> haven't examined it.

Both {skalduna} and {critata} (like every fu'ivla) can be used
in final position.

Both {skalduna'y-} and {critata'y-} (like for every fu'ivla) can
be used in non-final position.

{skalduny-} fails slinku'i: {le skaldunyna'a} = les-kal-dun-na'a,
so it cannot be used as a rafsi for {skalduna}.

{critaty-} is {cirko zei tatru zei}, so cannot be used as a
rafsi for {critata}.

> > Also, we need to revise "slinku'i" itself a bit if r-hyphens are allowed
> > when not required. We have a valid lujvo "li'erla'i" (li'e + r +
> > la'i). If we allow someone to add an affix on the front without removing
> > the "r" ("tos + li'e + r + la'i), we then need to disallow a potential
> > fu'ivla "sli'erla'i" (originally OK - good initial cluster, doesn't break
> > down into rafsi and/or gismu, used to pass to+sli'erla'i "slinku'i" test
> > but now will not). Making fu'ivla is a mine-field.
>
> Hmm...

Allowing r-hyphens after any CVV rafsi encroaches on fu'ivla
space, that is known. (The y rafsi after CVC has no effect on
fu'ivla on the other hand.) This minor encroachment however is
worth the simplification this brings to the user. Normal lujvo
have always had priority over fu'ivla anyway.

> > If "non-y cmavo can have non-final rafsi by adding 'y", then are we
> > removing the restriction that there must be a consonant cluster in the
> > first 5 non-'-non-y letters? "oi'ycai'ylujvo". How do they attach on
> > the left if they're vowel-initial - eg: klama + o + sutra =
> > klamywhatsutra?
>
> I think making rafsi from cmavo like this is crazy.

Why? We already allow several cmavo to have rafsi, and sometimes just
the one you need happens not to have a rafsi... If they don't prove
useful they won't be used, but as long as they are not harmful, why
not allow them?

> > "cmene can have inital rafsi by adding iy". Can names have "iy"
> > internally, or is that disallowed like la/lai/la'i/doi? Must the name be
> > entirely unstressed if it doesn't have the penultimate syllable? I don't
> > think it causes a problem, but I'm not yet sure.
>
> This too is crazy. {uiliym} has "iy", and it has no consonant cluster, so
> {uiliymiytavla} is not a word and would parse wrong.

In PEG it should parse correctly. Any number of iy are allowed
in cmene. You can think of {uiliym} as a hyphened name "Will-M",
or not, according to your taste.

> Cmene lujvo aren't
> nearly common enough to make this rule for them; the only one that comes to
> mind is {ctelr zei xasybakni}, which could just as well be called {xasybakni
> la ctelr}.

That would be {ctelriyxasybakni}.

> Both
> the PEG and valfendi should have the same set of valid words, so if a set of
> words can't be implemented in both methods easily, it's wrong.

I don't think you will have much trouble implementing extended rafsi,
as they are very regular and easy to recognize. I agree it is a very
good thing to run the set of test words through both parsers so that
there's less of a chance we are forgetting something.

> This doesn't
> mean that they'll accept the same set of speech streams; corner cases like
> {lekybumoi} can produce different output.

Ideally there would be one official rule for every case, including
corner cases. Each parser can then have special settings for deviations
for whatever reason, but the official rule would be just one.

In this case, {lekybumoi} is either a non-lojban word or
it is {le ky bu moi}, depending on whether we require officially
that every Cy cmavo must always be followed by a pause or only
when necessary. I prefer the latter, and that's what PEG does now,
but it could be done the other way too.

mu'o mi'e xorxes

__
Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.
http://promotions.yahoo.com/new_mail