Message-Id: <199511121421.JAA16150@locke.ccil.org>
Date:         Sun, 12 Nov 1995 14:14:52 +0000
Reply-To: ucleaar <ucleaar@UCL.AC.UK>
Sender: Lojban list <LOJBAN@CUVMB.BITNET>
From: ucleaar <ucleaar@UCL.AC.UK>
Subject:      Re: buffer vowel
To: John Cowan <cowan@LOCKE.CCIL.ORG>
Status: OR

Chris asks why we need the buffer vowel - why we should bother to
make the phonology easier. My response is (i) that it is surely to
the advantage of the language that it be easier rather than harder,
since the prevailing wish is that the language be used as well as
admired, and (ii) that the consonant clusters are one of the
features most liable to attract criticism from a novice or outsider,
and it is in such cases useful to be able to answer that there are
no obligatory consonant clusters.

John:
> The phonology is broken in the area of buffer vowels.
[...]
> I have added a note to the phonology paper saying that those who
> use buffers should pronounce their "real" vowels longer, thus:
> [kI la: ma:] where [I] is the buffer and [:] is the IPA vowel
> length diacritic.

This in effect makes length phonologically contrastive, but also
"fixes" the problem. Is that fix really desirable, especially when
some unstressed syllables must also be long?

> Unfortunately, I fear that although the phonology is broken, it
> may be too late to fix it.  Either we have to define the buffer
> as a definite though optional vowel, or we have to revise the
> morphology to allow buffer-hyphen equivalence (meaning that
> "patfymamta" and "patfmamta" mean the same thing -- currently the
> latter is a dubious le'avla). This is scary, although it might work
> if it turns out that all le'avla that are banned either fail the
> slinku'i test or involve nonstandard medial consonant triples like
> "tfm" which is "t/f/m".

I vote for buffer-hyphen equivalence.

As for the slinkui test, I don't see how it's relevant here.
Also, I've never understood the rationale for it. The tosmabru
test says if a string is potentially ambiguous between lujvo
and cmavo+lujvo, then the latter wins. The slinkui test says
if a string is potentially ambiguous between lujvo and cmavo
+lujvo, either lujvo is banned. I am confused.

> But if neither strategy can be made to work, then we just have to
> choke down buffering as a known flaw in the language.

Or do as Chris suggests, and scrap buffering.

---
And