[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lojban] Re: Is there any demand for LoCCan3?

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&notif_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, 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). 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 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.