[YG Conlang Archives] > [engelang group] > messages [Date Index] [Thread Index] >


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

Re: [engelang] Xorban: Semantics of "l-" (and "s-" and "r-")



John E Clifford, On 09/09/2012 03:26:
*From:* And Rosta <and.rosta@hidden.email> John E Clifford, On
08/09/2012 19:35:
So, then, how do we tell if la mlta xkra is true? We squint,
apparently, but at what? I don't even know where to look.

You take the logical form, add in the content from the encyclopedia
entries (from l-, mlt- and xkr-), and see how closely the
proposition matches the world. That won't be a formalizable process
(in the sort of loglang in question).

Neato. Now what is the encyclopedic entry on lV?

Within the rules for logical forms are rules of equivalence between logical forms. Some rules of equivalence serve to define lV, and I think the entry on lV would be empty. The equivalence rules would probably involve sV and rV, whose encyclopedia entries are what one would expect.
If all you want is predicate-argument and operator-variable
structure, then what exactly is your problem with Lojban, which has
that. The obvious answer is that it is not consistent in its use of
variables, replacing them sometimes by repetitions, sometimes by
pronouns, and so on.

The problems with Lojban are firstly that it doesn't in fact unambiguously encode logical form, secondly that it is full or cruft, garbage and bodging, and thirdly that it is insufficiently ergonomic, for various reasons especially including longwindedness.

Xorban even at this early stage is fixing most of those problems.

So far, the Xorban design is doing nicely on being consistent (if
occasionally obscure) but not so good on being speakable (a common
problem in loglangs, although more often for parentheses than
variables).

Once a loglang has met the key criterion of unambiguously encoding logical forms, the main criterion for choosing among them would be usability -- how speakable and hearer-comprehendable it is.

I only know two loglangs to have met the key criterion, and the only one visible in public is Xorban. it would be good to have alternatives that are (even) more usable, so this we could work on usability.
I've given you one plausible interpretation, that l is an ever
 leftmost quantifier that picks out a bunch of items and sticks
 with thm throughout its scope.

I don't see problems with it. Crucially, if Y is true of
something that is that bunch, then Y is true of everything that
is that bunch -- given that it's a single bunch.

This seems to me a rather different point than what has been said
formally. The formalism has been la Ra Pa <=> re RePe and la Ra Pa
 <=> se Re Pe. But what you are saying seems to be la Ra Pa <=> re
e=a Pe and similarly for s.

I don't understand what your "re e=a Pe" means, or how it differs
from "re Re Pe".

We seem to agree that in "lA bcdA fghA", A is a single thing, and is
a bunch of bcds, and we also seem to agree that maximal leftmost
scope is fine, but for a case where it contains a variable bound by
something outside the scope of lV. So if we disagree about anything
it must be on what a bcd is. Or am I missing something?

Well, I am having second thoughts about that leftmost scope idea and
seeing other problems with it, especially for some of the predefined
cases of Xorban. But I may be wrong about those worries and and even
find a qorkaround for leftmost rules generally. My main problem
comes from your explanation for the equivalences between the lV
sentence and both the rV bound and the sV bound, with the same
restriction and the same predicate. You seem to suggest that, given
la bcda fgha, re bcde refers only to the bcds among la bcd and
similarly for si bcdi. That is the peculiarity that I was trying to
point out in my rewrite (and actually, I am not sure whether it is
a=e or e[epsilon]a that is involved). That does seem to be what you
say and I don't see how to make the equations work otherwise.

OKay, thanks for explaining. Yes, I was saying "la Ra Pa" <=> "re [is-A]e Pe" and "se [is-A]e Pe".  (Not epsilon and probably not "=".)

--And.