Received: from mail-gg0-f189.google.com ([209.85.161.189]:46657) by stodi.digitalkingdom.org with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) (envelope-from ) id 1SoGJe-0004Wj-9f; Mon, 09 Jul 2012 08:56:04 -0700 Received: by ggke5 with SMTP id e5sf13807088ggk.16 for ; Mon, 09 Jul 2012 08:55:56 -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=9BLT6Uty5FwV4MN8NHtyMsZR03KX7h3LL3fkNcagBq8=; b=5KuKEgmhd+K0uNdb9XUNfZHtuxUIDNYrsKIoWUgbaUkvaBv/I4qZHX4LrxUrGS3DHf XhV4/oNmZ8QHQzDPne3eB2TgsLKn/Dz5d3CDUKQPIP8V8KS2CQJupnp8T4+IfBRQh0mo FQw+YSHKSdviCeKZCqsB4azP1AX14Gu1XxWOo= Received: by 10.68.197.161 with SMTP id iv1mr2341862pbc.0.1341849355735; Mon, 09 Jul 2012 08:55:55 -0700 (PDT) X-BeenThere: lojban@googlegroups.com Received: by 10.68.233.198 with SMTP id ty6ls11338476pbc.2.gmail; Mon, 09 Jul 2012 08:55:54 -0700 (PDT) Received: by 10.68.222.197 with SMTP id qo5mr2542412pbc.13.1341849354627; Mon, 09 Jul 2012 08:55:54 -0700 (PDT) Date: Mon, 9 Jul 2012 08:55:54 -0700 (PDT) From: la gleki To: lojban@googlegroups.com Message-Id: <09cb2338-05cb-4140-871f-f6532a77b6eb@googlegroups.com> In-Reply-To: <4FF9D244.4020603@gmail.com> References: <90a7e54c-42fe-4ee0-9693-8155db9a7646@googlegroups.com> <62818d3a-c188-43d5-ad25-09c4cc9aca6c@googlegroups.com> <1341252212.22198.YahooMailNeo@web184415.mail.bf1.yahoo.com> <4FF20621.1090100@lojban.org> <1341333405.7836.YahooMailNeo@web184416.mail.bf1.yahoo.com> <4FF74E66.1020605@gmail.com> <94270542-27d3-458e-af31-9361f81841cc@googlegroups.com> <4FF9D244.4020603@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_1079_10853419.1341849354083" X-Spam-Score: -0.7 (/) X-Spam_score: -0.7 X-Spam_score_int: -6 X-Spam_bar: / ------=_Part_1079_10853419.1341849354083 Content-Type: text/plain; charset=ISO-8859-1 On Sunday, July 8, 2012 10:32:36 PM UTC+4, And Rosta wrote: > > la gleki, On 07/07/2012 03:33: > > On Saturday, July 7, 2012 12:45:26 AM UTC+4, And Rosta wrote: > > I define a loglang as one that can unambiguously encode any explicit > > predicate logic formula in a way that is no less concise than the way > > natlangs would express the formula (with much greater ambiguity and > > leaving much more to be glorked from context). The relevance of the > > concision requirement is firstly that without it, the gain in clarity > > is not necessarily worth the effort of greater verbosity; rather, the > > goal is to up the clarity-to-verbosity ratio. And secondly, designing > > a language that can unambiguously encode any explicit predicate logic > > formula is trivially easy; it's only the concision requirement that > > makes the challenge difficult (or maybe impossible). Not everybody > > defines their sought-for loglang by these criteria. For example, John > > Clifford and Martin Bays are very preoccupied with having a highly > > specified semantics for the loglang, which is something I'm rather > > unsympathetic to. > > > > Just several hours ago I posted a short note > > < > https://www.facebook.com/photo.php?fbid=236029819851609&set=a.200050570116201.43269.100003337779349&type=1&theater¬if_t=photo_comment> > > > on another critique of Lojban from the side semanticophils. > > I've looked at that note, and I think it misunderstands what John Q is > saying. The point in the intro is about how the basic lexicon covers > semantic space, i.e. how you select your inventory of basic morphemes It is. It says how you select root words. They all appear to be taken from English semantics etc. > , whereas the point in the last chapter pertains to a kind of inventory of > primitives for a metalanguage for defining meanings (i.e. a Wierzickan-type > enterprise). Indeed, he wanted to rearrange semantic space using his new affixes not always having equivalents in most common languages. But he admits that he fails to do that for everything. I can see that he has roots for "NECKTIE/CRAVATTE". But if so then whty criticising Lojban if you have the same? It's nice that you are creating a new language. But why stretching the truth about your own child? Ithkuil doesn't resolve such issue and nobody is likely to make huge progress here. Still we can argue about this in theory but practice shows that in most cases Ithkuil affixes correspond to Lojbanic words (not taking into account that Lojbanic predicates have arguments whereas Ithkuil's do not or the meaning of their derivatives is postulated which wipes out all charm). The remaining part of Ithkuil is nevetherless worth studying. He accumulated features of many nice conlangs in his project. So we should be friends with him as well (as will all the other thinkers). I respect John Quijada's work very much. It's not fighting with him. Just defending Lojban. He's talking about two different things. Incidentally, I disagree with the > idea of a closed-set of primitives, as something philosophically untenable, > tho an open set of primitives is something I'm in favour of. > > > It's easy to think of ways of drastically improving on the Lojban > > design. > > > > For example, discard rafsi > > > > How would you distinguish between {latcribe} and {mlatu cribe} then? > > The latter is definitely not panda. > > That question can't really be answered without imagining an alternative > morphology. Suppose the parser worked strictly left-to-right with no > lookahead, and we said that every V is word-final. Then if gismu were CCV, > a form C1-[C2-C3-V] could be used to indicate that it was non-final in a > compound, the C1 being functionally equivalent to {zei}. But more > importantly, the number of cmavo should be shrunk to the minimum, and the > length of cmavo and gismu should be inversely proportional to their > frequency. > > > , make all gismu CCV -- becomes conciser and easier to learn in one > go. > > > > Yes, lowering signal-to-noise ratio even further ;) > > Indeed. Concision is far more important than noise-resistance, and it is > far easier to give a basically concise system an expanded noise-resistant > version than to give a basically verbose noise-resistant system a concise > form. > > > Or discard almost all selmaho, default to Polish notation syntax, > > > > Can you provide us with any draft of such language? > > It's not really worth the effort, since the feasibility of the system is > pretty obvious: ordinary predicate logic is consistent with Polish and > Reverse Polish notations.I would insist on something that can be parsed > incrementally left-to-right with no lookahead, which keeps everything > simple. > > > and you have something much conciser, much more easy to learn, much > more easy to parse. I suppose that even these changes are so drastic that > they'd amount to discarding the current Loglan--Lojban entirely and > starting over, but I think a complete redesign is anyway necessary because > of the one fundamental design challenge of a loglang, which is the > challenge of representing where two argument-places have the same value > (e.g. in "John laughed and sneezed", where the argument-place of John(), of > Laugh() and of Sneeze() have the same value): specifically, the challenge > is to represent that in a concise and human-usable way (bearing in mind > that a normal sentence might involve dozens of groups of argument-places > that have the same value). You c > > ould call this loglang "LoCCan3", but, unlike John Clifford's > vision, it couldn't be achieved by incremental revisions to LoCCan2. > > > > I can praise any improvements backward compatible with the current > language. But any new loglangs not having a parser just don't exist to me. > They are just projects, not working loglangs. > > I don't know what counts as backward-compatibility. Xorxes's proposals > probably strike a balance of worthwhileness and backward-compatibility. A > "working parser" strikes me as an irrelevance: the parsing algorithm for an > ergonomic loglang should be so simple that its parsability should be > self-evident. > > --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/-/YJA_ZrdYxXsJ. 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_1079_10853419.1341849354083 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sunday, July 8, 2012 10:32:36 PM UTC+4, And Rosta wrote:la gleki, On 07/07/2012 03:33:
> On Saturday, July 7, 2012 12:45:26 AM UTC+4, And Rosta wrote:
> I define a loglang as one that can unambiguously encode any explic= it
> predicate logic formula in a way that is no less concise than the = way
> natlangs would express the formula (with much greater ambiguity an= d
> leaving much more to be glorked from context). The relevance of th= e
> concision requirement is firstly that without it, the gain in clar= ity
> is not necessarily worth the effort of greater verbosity; rather, = the
> goal is to up the clarity-to-verbosity ratio. And secondly, design= ing
> a language that can unambiguously encode any explicit predicate lo= gic
> formula is trivially easy; it's only the concision requirement tha= t
> makes the challenge difficult (or maybe impossible). Not everybody
> defines their sought-for loglang by these criteria. For example, J= ohn
> Clifford and Martin Bays are very preoccupied with having a highly
> specified semantics for the loglang, which is something I'm rather
> unsympathetic to.
>
> Just several hours ago I posted a short note
> <https://www.facebook.= com/photo.php?fbid=3D236029819851609&set=3Da.20005057011= 6201.43269.100003337779349&type=3D1&theater&notif_t= =3Dphoto_comment>
> on another critique of Lojban from the side semanticophils.

I've looked at that note, and I think it misunderstands what John Q is = saying. The point in the intro is about how the basic lexicon covers semant= ic space, i.e. how you select your inventory of basic morphemes

It is. It says how you select root words. They all app= ear to be taken from English semantics etc.
, whereas the point in the last chapter pertains to a ki= nd of inventory of primitives for a metalanguage for defining meanings (i.e= . a Wierzickan-type enterprise).
Indeed, he wanted to rear= range semantic space using his new affixes not always having equivalents in= most common languages. But he admits  that he fails to do that for ev= erything. I can see that he has roots for "NECKTIE/CRAVATTE". But if so the= n whty criticising Lojban if you have the same?
It's nice that yo= u are creating a new language. But why stretching the truth about your own = child? Ithkuil doesn't resolve such issue and nobody is likely to make huge= progress here.
Still we can argue about this in theory but pract= ice shows that in most cases Ithkuil affixes correspond to Lojbanic words (= not taking into account that Lojbanic predicates have arguments whereas Ith= kuil's do not or the meaning of their derivatives is postulated which wipes= out all charm).
The remaining part of Ithkuil is nevetherless wo= rth studying. He accumulated features of many nice conlangs in his project.=
So we should be friends with him as well (as will all the other thinker= s). I respect John Quijada's work very much.
It's not fighting wi= th him. Just defending Lojban.

He's talking about two different things. Incidentally= , I disagree with the idea of a closed-set of primitives, as something phil= osophically untenable, tho an open set of primitives is something I'm in fa= vour of.

> It's easy to think of ways of drastically improving on the Lojban
> design.
>
> For example, discard rafsi
>
> How would you distinguish between {latcribe} and {mlatu cribe} the= n?
> The latter is definitely not panda.

That question can't really be answered without imagining an alternative= morphology. Suppose the parser worked strictly left-to-right with no looka= head, and we said that every V is word-final. Then if gismu were CCV, a for= m C1-[C2-C3-V] could be used to indicate that it was non-final in a compoun= d, the C1 being functionally equivalent to {zei}. But more importantly, the= number of cmavo should be shrunk to the minimum, and the length of cmavo a= nd gismu should be inversely proportional to their frequency.

>     , make all gismu CCV -- becomes conciser and easier = to learn in one go.
>
> Yes, lowering signal-to-noise ratio even further ;)

Indeed. Concision is far more important than noise-resistance, and it i= s far easier to give a basically concise system an expanded noise-resistant= version than to give a basically verbose noise-resistant system a concise = form.

>     Or discard almost all selmaho, default to Polish not= ation syntax,
>
> Can you provide us with any draft of such language?

It's not really worth the effort, since the feasibility of the system i= s pretty obvious: ordinary predicate logic is consistent with Polish and Re= verse Polish notations.I would insist on something that can be parsed incre= mentally left-to-right with no lookahead, which keeps everything simple.

>     and you have something much conciser, much more easy= to learn, much more easy to parse. I suppose that even these changes are s= o drastic that they'd amount to discarding the current Loglan--Lojban entir= ely and starting over, but I think a complete redesign is anyway necessary = because of the one fundamental design challenge of a loglang, which is the = challenge of representing where two argument-places have the same value (e.= g. in "John laughed and sneezed", where the argument-place of John(), of La= ugh() and of Sneeze() have the same value): specifically, the challenge is = to represent that in a concise and human-usable way (bearing in mind that a= normal sentence might involve dozens of groups of argument-places that hav= e the same value). You c
>     ould call this loglang "LoCCan3", but, unlike John C= lifford's vision, it couldn't be achieved by incremental revisions to LoCCa= n2.
>
> I can praise any improvements backward compatible with the current= language. But any new loglangs not having a parser just don't exist to me.= They are just projects, not working loglangs.

I don't know what counts as backward-compatibility. Xorxes's proposals = probably strike a balance of worthwhileness and backward-compatibility. A "= working parser" strikes me as an irrelevance: the parsing algorithm for an = ergonomic loglang should be so simple that its parsability should be self-e= vident.

--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/-/YJ= A_ZrdYxXsJ.
=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_1079_10853419.1341849354083--