Received: from mail-qa0-f56.google.com ([209.85.216.56]:37974) by stodi.digitalkingdom.org with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) (envelope-from ) id 1Spc1H-0001zV-BI; Fri, 13 Jul 2012 02:18:44 -0700 Received: by qaas11 with SMTP id s11sf467635qaa.1 for ; Fri, 13 Jul 2012 02:18:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=beta; h=x-beenthere:date:from:to:message-id:in-reply-to:references:subject :mime-version:x-original-sender:x-original-authentication-results :reply-to:precedence:mailing-list:list-id:x-google-group-id :list-post:list-help:list-archive:sender:list-subscribe :list-unsubscribe:content-type; bh=HQlE7qz5iNs1LCKStaGClzE7PyeZFqqX0iGaJTsgRbk=; b=OPHI1K/JWQF1mVFSf36E33hVP7kgTKKNBJWi4eceiLH8mugzXYnBxxLXW8pxE8bdHM 5d0v4XTNXz/CCxRVO7NDGPKKVjN3NeHQIQeEgj+Zo1XdWoKm9ccmytNk9xK6p8xDXbXm rX5FXg7SnRWgBhqIFsS3aZyJG9EbMbw3krV5g= Received: by 10.52.97.102 with SMTP id dz6mr10655vdb.2.1342171112517; Fri, 13 Jul 2012 02:18:32 -0700 (PDT) X-BeenThere: lojban@googlegroups.com Received: by 10.220.221.197 with SMTP id id5ls1597534vcb.5.gmail; Fri, 13 Jul 2012 02:18:31 -0700 (PDT) Received: by 10.52.34.8 with SMTP id v8mr9876vdi.5.1342171111005; Fri, 13 Jul 2012 02:18:31 -0700 (PDT) Date: Fri, 13 Jul 2012 02:18:30 -0700 (PDT) From: Gleki Arxokuna To: lojban@googlegroups.com Message-Id: In-Reply-To: <4FFDC7C8.2010707@gmail.com> References: <90a7e54c-42fe-4ee0-9693-8155db9a7646@googlegroups.com> <4FFDC7C8.2010707@gmail.com> Subject: Re: [lojban] Re: Is there any demand for LoCCan3? MIME-Version: 1.0 X-Original-Sender: gleki.is.my.name@gmail.com X-Original-Authentication-Results: ls.google.com; spf=pass (google.com: domain of gleki.is.my.name@gmail.com designates internal as permitted sender) smtp.mail=gleki.is.my.name@gmail.com; dkim=pass header.i=@gmail.com Reply-To: lojban@googlegroups.com Precedence: list Mailing-list: list lojban@googlegroups.com; contact lojban+owners@googlegroups.com List-ID: X-Google-Group-Id: 1004133512417 List-Post: , List-Help: , List-Archive: Sender: lojban@googlegroups.com List-Subscribe: , List-Unsubscribe: , Content-Type: multipart/alternative; boundary="----=_Part_645_8108164.1342171110596" X-Spam-Score: -0.7 (/) X-Spam_score: -0.7 X-Spam_score_int: -6 X-Spam_bar: / ------=_Part_645_8108164.1342171110596 Content-Type: text/plain; charset=ISO-8859-1 On Wednesday, July 11, 2012 10:36:56 PM UTC+4, And Rosta wrote: > > la gleki, On 11/07/2012 08:41: > > Let's name > > Loglan = LoCCan 1.0 > > Lojban = LoCCan 2.0 > > Lojban after xorlo reform = LoCCan 2.1 > > As I understand it, Lojban was more of a fork from Loglan than an > improvement of it -- essentially a Loglan relex with some other subsequent > mostly gratuitous 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=gismu 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 > of 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 > means recovering the logical form, not merely assigning some meaningless > structure to surface phonology, as in the current so-called parser. > But what can stop us from using existing predicativeness of the current Lojban? If you don't like cmavo don't use them if you can. It's you speech style. It's not a separate language. > Apply some sort of Huffman-encoding type scheme to at least morphemes > (possibly to morpheme strings). Possibly temper this by the desirability of > having some sort of phonosemantic patterning among morphemes, for mnemonic > purposes. > > 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 > enough, 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 for purpose. (I suppose that if future research were to show that > the fundamental loglang problem is insoluble, then one would after all want > the best possible LoCCan version, as the language least unfit for purpose.) > To apprehend the fundamental loglang problem, imagine Lojban without > {zo'e}, and then try to think how it could be redesigned to avoid being > impossibly longwinded 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 > forms, complex brivla (lujvo) would be necessary only when the forms were > not semantically compositional, i.e. when the meaning of the whole is not > completely predictable from the meaning of the parts. The morphological > translucence (semicompositionality) of lujvo would serve a merely mnemonic > purpose. > > > 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 > something akin to rafybri as its basic device. > > --And. > -- You received this message because you are subscribed to the Google Groups "lojban" group. To view this discussion on the web visit https://groups.google.com/d/msg/lojban/-/WbSKSKHGefwJ. To post to this group, send email to lojban@googlegroups.com. To unsubscribe from this group, send email to lojban+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/lojban?hl=en. ------=_Part_645_8108164.1342171110596 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wednesday, July 11, 2012 10:36:56 PM UTC+4, And Rosta wrote: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 impro= vement of it -- essentially a Loglan relex with some other subsequent mostl= y gratuitous 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 versio= ns
> of gismu

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

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

 

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 parsabilit= y means recovering the logical form, not merely assigning some meaningless = structure to surface phonology, as in the current so-called parser.
But what can stop us from using existing predicativen= ess of the current Lojban? If you don't like cmavo don't use them if you ca= n. It's you speech style. It's not a separate language.


Apply some sort of Huffman-encoding type scheme to at least morphemes (= possibly to morpheme strings). Possibly temper this by the desirability of = having some sort of phonosemantic patterning among morphemes, for mnemonic = purposes.

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 e= nough, and I don't see much point in investing a lot of effort into creatin= g a language whose design is miles better than Lojban's but is still not fi= t for purpose. (I suppose that if future research were to show that the fun= damental loglang problem is insoluble, then one would after all want the be= st possible LoCCan version, as the language least unfit for purpose.)  = ;To apprehend the fundamental loglang problem, imagine Lojban without {zo'e= }, and then try to think how it could be redesigned to avoid being impossib= ly longwinded and impossibly taxing on the memory of (especially) the heare= r/reader.

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

Quite so. Since simplex brivla (gismu) would already have maximally sho= rt forms, complex brivla (lujvo) would be necessary only when the forms wer= e not semantically compositional, i.e. when the meaning of the whole is not= completely predictable from the meaning of the parts. The morphological tr= anslucence (semicompositionality) of lujvo would serve a merely mnemonic pu= rpose.

> 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 broke= n
> vague ambiguous internal structure of tanru with no places. I don'= t
> think And Rosta's CCV suggestion is much better than rafybri (rafy= bri
> can be used immediately as they add new rules but donot destroy an= y
> old rules). But let's wait until ey presents something.

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

--And.

--
You received this message because you are subscribed to the Google Groups "= lojban" group.
To view this discussion on the web visit https://groups.google.com/d/msg/lojban/-/Wb= SKSKHGefwJ.
=20 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.
------=_Part_645_8108164.1342171110596--