Received: from mail-gh0-f189.google.com ([209.85.160.189]:36224) by stodi.digitalkingdom.org with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) (envelope-from ) id 1SoRkm-00027R-K5; Mon, 09 Jul 2012 21:08:58 -0700 Received: by ghbf16 with SMTP id f16sf14387899ghb.16 for ; Mon, 09 Jul 2012 21:08:42 -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=rWQuIH6Wrsb44nBumELyzwD1nKjfZ3i5zCOpZydjzhA=; b=x3jq3S7tmoLSOzzVkPt2bmpoaAJ7fzgZ9UU88Kp86T/RYrUTPrDvayKZ8cUzvrHxZB GB0R9BK1ga1wW6W1LkUim3hKsOFTUFwBM36bI5gLNL2ywCekA6KU+twbvSS5uWeu43de IWQrjfE+mBLrLnOS0b8dvaT8nuh7LH1ukn/cY= Received: by 10.52.66.137 with SMTP id f9mr2595670vdt.14.1341893322199; Mon, 09 Jul 2012 21:08:42 -0700 (PDT) X-BeenThere: lojban@googlegroups.com Received: by 10.220.119.137 with SMTP id z9ls640602vcq.2.gmail; Mon, 09 Jul 2012 21:08:41 -0700 (PDT) Received: by 10.52.71.7 with SMTP id q7mr1609624vdu.20.1341893321484; Mon, 09 Jul 2012 21:08:41 -0700 (PDT) Date: Mon, 9 Jul 2012 21:08:40 -0700 (PDT) From: la gleki To: lojban@googlegroups.com Message-Id: <06610b3e-5f3f-47d1-9bf5-2cca2e9e0508@googlegroups.com> In-Reply-To: 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> <09cb2338-05cb-4140-871f-f6532a77b6eb@googlegroups.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_81_264799.1341893320931" X-Spam-Score: -0.7 (/) X-Spam_score: -0.7 X-Spam_score_int: -6 X-Spam_bar: / ------=_Part_81_264799.1341893320931 Content-Type: text/plain; charset=ISO-8859-1 On Tuesday, July 10, 2012 3:27:55 AM UTC+4, stevo wrote: > > If LoCCan3 is backward compatible with Lojban, then it's still Lojban, and > not really LoCCan3, although maybe LoCCan2.1. > LoCCan3 will be different from Lojban. > Indeed.We should use terms more carefully. > > stevo > > On Mon, Jul 9, 2012 at 11:55 AM, la gleki wrote: > >> >> >> 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 >>> > >> 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. >> > > -- 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/-/-RV46duKbUcJ. 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_81_264799.1341893320931 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tuesday, July 10, 2012 3:27:55 AM UTC+4, stevo wrote:If LoCCan3 is backward compatible with Lo= jban, then it's still Lojban, and not really LoCCan3, although maybe LoCCan= 2.1. 
LoCCan3 will be different from Lojban. 
Indeed.We should use terms more carefully.
 

stevo
On Mon, Jul 9, 2012 at 11:55 AM, la gleki <gleki.is.my.name@gmail= .com> wrote:


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.200050570116201.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 al= l 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 semanti= c 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 c= an see that he has roots for "NECKTIE/CRAVATTE". But if so then whty critic= ising 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 th= is in theory but practice shows that in most cases Ithkuil affixes correspo= nd 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 accum= ulated features of many nice conlangs in his project.
So we should be fr= iends with him as well (as will all the other thinkers). I respect John Qui= jada's work very much.
It's not fighting with him. Just defending Lojban.

=
He's talking about two diffe= rent things. Incidentally, I disagree with the idea of a closed-set of prim= itives, as something philosophically untenable, tho an open set of primitiv= es 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} 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/-/YJA_ZrdYxXsJ.

=20 To post to this group, send email to lojban@googlegroups.com.
To unsubscribe from this group, send email to lojban+unsubscribe@googl= egroups.com.
For more options, visit this group at http://groups.google.com/group/= lojban?hl=3Den.

--
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/-/-R= V46duKbUcJ.
=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_81_264799.1341893320931--