Received-SPF: pass (google.com: domain of and.rosta@gmail.com designates 74.125.83.45 as permitted sender) client-ip=74.125.83.45;
Message-ID: <4FFDC7C8.2010707@gmail.com>
Date: Wed, 11 Jul 2012 19:36:56 +0100
From: And Rosta <and.rosta@gmail.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20
MIME-Version: 1.0
To: lojban@googlegroups.com
Subject: Re: [lojban] Re: Is there any demand for LoCCan3?
References: <90a7e54c-42fe-4ee0-9693-8155db9a7646@googlegroups.com> <f5113f81-1797-4d4b-8c39-2d96ed42cfa2@googlegroups.com>
In-Reply-To: <f5113f81-1797-4d4b-8c39-2d96ed42cfa2@googlegroups.com>
Reply-To: lojban@googlegroups.com
Precedence: list
Mailing-list: list lojban@googlegroups.com; contact lojban+owners@googlegroups.com
Sender: lojban@googlegroups.com
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Spam_score: -0.7
X-Spam_score_int: -6
X-Spam_bar: /

la gleki, On 11/07/2012 08:41:
> Let's name
> Loglan =3D LoCCan 1.0
> Lojban =3D LoCCan 2.0
> Lojban after xorlo reform =3D LoCCan 2.1

As I understand it, Lojban was more of a fork from Loglan than an improveme=
nt of it -- essentially a Loglan relex with some other subsequent mostly gr=
atuitous changes.

Nevertheless, your terminology is convenient.

> 1. Backward-incompatible And Rosta's project of CCV-gismu equal to
> rafsi and CCVrCCV lujvo where "r" is a buffer consonant.

[I had in mind this "r" being any consonant, not just /r/.]

This lowers
> signal-to-noise ratio but makes learning rafsi=3Dgismu much easier (no
> separate forms for gismu/rafsi). This can possibly remove the need in
> many modal tags that are actually duplicates and compressed versions
> of gismu

I have no such project. The CCV thing was just an idea tossed out, as one o=
f the many easy ways of improving on Lojban.

If I was asked for advice on LoCCan3, it'd be this, in the first instance:

Discard the LoCCan2 syntax, then start with predicate logic, and enrich it =
only with what predicate logic can't express or accommodate. Insist on the =
syntax being incrementally parsable with no lookahead, where parsability me=
ans recovering the logical form, not merely assigning some meaningless stru=
cture to surface phonology, as in the current so-called parser.

Apply some sort of Huffman-encoding type scheme to at least morphemes (poss=
ibly to morpheme strings). Possibly temper this by the desirability of havi=
ng some sort of phonosemantic patterning among morphemes, for mnemonic purp=
oses.

That's not be the end of my advice, but it'd be the key bits.

HOWEVER, I think that a LoCCan3 that did that would still not be good enoug=
h, and I don't see much point in investing a lot of effort into creating a =
language whose design is miles better than Lojban's but is still not fit fo=
r purpose. (I suppose that if future research were to show that the fundame=
ntal loglang problem is insoluble, then one would after all want the best p=
ossible LoCCan version, as the language least unfit for purpose.)  To appre=
hend the fundamental loglang problem, imagine Lojban without {zo'e}, and th=
en try to think how it could be redesigned to avoid being impossibly longwi=
nded and impossibly taxing on the memory of (especially) the hearer/reader.

> And Rosta's suggests relexing gismu. Still lujvo in eir language will
> have no internal predicate structure.

Quite so. Since simplex brivla (gismu) would already have maximally short f=
orms, complex brivla (lujvo) would be necessary only when the forms were no=
t semantically compositional, i.e. when the meaning of the whole is not com=
pletely predictable from the meaning of the parts. The morphological transl=
ucence (semicompositionality) of lujvo would serve a merely mnemonic purpos=
e.

> Rafybri compress some bridi preserving sumti places between two or
> more gismu. They are equivalent in meaning to some lujvo but donot
> require learning them by rot. However, ordinary lujvo retain broken
> vague ambiguous internal structure of tanru with no places. I don't
> think And Rosta's CCV suggestion is much better than rafybri (rafybri
> can be used immediately as they add new rules but donot destroy any
> old rules). But let's wait until ey presents something.

For the reasons given above, rafybri would be redundant in a well-designed =
loglan. Or, to put it a different way, a well designed loglan would use som=
ething akin to rafybri as its basic device.

--And.

--=20
You received this message because you are subscribed to the Google Groups "=
lojban" group.
To post to this group, send email to lojban@googlegroups.com.
To unsubscribe from this group, send email to lojban+unsubscribe@googlegrou=
ps.com.
For more options, visit this group at http://groups.google.com/group/lojban=
?hl=3Den.