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.