Received-SPF: none (google.com: mbays@sdf.org does not designate permitted sender hosts) client-ip=192.94.73.24;
Date: Sat, 11 Oct 2014 21:24:27 -0400
From: Martin Bays <mbays@sdf.org>
To: lojban@googlegroups.com
Subject: Re: [lojban] Re: tersmu 0.2
Message-ID: <20141012012427.GF23876@gonzales>
References: <20141009010533.GF18854@gonzales>
 <CAO7tK2erLDXJy5jOAx7--+vamH9brWJNSH2K82ACJgKbDVvD8g@mail.gmail.com>
 <20141009233031.GC1592@gonzales>
 <CAO7tK2cpdLRm8AOtHjADMKMP10uFu_N4mfddsP0-q07YnFzSLA@mail.gmail.com>
 <20141010234033.GG22868@gonzales>
 <CAO7tK2dXyFzuCiv3g18B2poF3YZwE4RQFTTvdfXGVXuycWmLyw@mail.gmail.com>
 <20141011021201.GH22868@gonzales>
 <CAO7tK2c_S3hC5K3eqSkmFjzZT4F5BRFLJ_+X44N212sygj_VGw@mail.gmail.com>
 <20141011143749.GD23876@gonzales>
 <CAO7tK2dEB=OsT6hkw1SRzPMRV6qOm7LpNXapdwKAb8s9y889oA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="yRA+Bmk8aPhU85Qt"
Content-Disposition: inline
In-Reply-To: <CAO7tK2dEB=OsT6hkw1SRzPMRV6qOm7LpNXapdwKAb8s9y889oA@mail.gmail.com>
X-cunselcu'a-valsi: mifra
User-Agent: Mutt/1.5.22 (2013-10-16)
X-Original-Sender: mbays@sdf.org
X-Original-Authentication-Results: gmr-mx.google.com;       spf=neutral
 (google.com: mbays@sdf.org does not designate permitted sender hosts) smtp.mail=mbays@sdf.org
Reply-To: lojban@googlegroups.com
Precedence: list
Mailing-list: list lojban@googlegroups.com; contact lojban+owners@googlegroups.com
List-ID: <lojban.googlegroups.com>
X-Google-Group-Id: 1004133512417
List-Post: <http://groups.google.com/group/lojban/post>, <mailto:lojban@googlegroups.com>
List-Help: <http://groups.google.com/support/>, <mailto:lojban+help@googlegroups.com>
List-Archive: <http://groups.google.com/group/lojban
Sender: lojban@googlegroups.com
List-Subscribe: <http://groups.google.com/group/lojban/subscribe>, <mailto:lojban+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+1004133512417+unsubscribe@googlegroups.com>,
 <http://groups.google.com/group/lojban/subscribe>
X-Spam-Score: -1.9 (-)
X-Spam_score: -1.9
X-Spam_score_int: -18
X-Spam_bar: -


--yRA+Bmk8aPhU85Qt
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

* Saturday, 2014-10-11 at 13:34 -0300 - Jorge Llamb=EDas <jjllambias@gmail.=
com>:

> On Sat, Oct 11, 2014 at 11:37 AM, Martin Bays <mbays@sdf.org> wrote:
> > * Saturday, 2014-10-11 at 08:58 -0300 - Jorge Llamb=EDas
> > > On Fri, Oct 10, 2014 at 11:12 PM, Martin Bays <mbays@sdf.org> wrote:
> > > > (So then tu'a needing opacity is no longer an argument that the res=
t of
> > > > LAhE should get it...)
> It's still the case that "tu'a" places the operators at the minimum of the
> three scopes available to it,
* Saturday, 2014-10-11 at 14:25 -0300 - Jorge Llamb=EDas <jjllambias@gmail.=
com>:
} [level 1 zo'u] mi djica lo poi'i [level 2 zo'u] ke'a du'u [level3 zo'u]
} da co'e
> so it's reasonable for the others to place them at the minimum of the
> two scopes they have available. Also for "na'e bo" and for "lu'a" the
> minimum scope seems to be the more useful one. If based just on
> usefulness LAhE would have to be split into different classes with
> different logical behaviors.
>=20
> Or perhaps we need to reevaluate the definition of some of these LAhEs. I
> wouldn't mind for example making "lu'i A .e B" the set of those things th=
at
> are both among A and among B, which would require redefining "lu'i" as "lo
> selcmi be ro me", with three potential scope levels just as "tu'a" has, a=
nd
> with the minimum being the correct one.

I think we should aim for regularity wherever possible.

If {tu'a} has to be magic, so be it. I don't see an alternative if
e.g. {tu'a re broda} -> {lo su'u re broda cu co'e} is supposed to be
(roughly) correct.

Here by "magic", I really mean that special-purpose code will be needed
in the parser for the case of {tu'a}.

So I think we should aim to find a single rule which will handle all
qualifiers but {tu'a}.

Let's think it through from scratch.

The simplest approach, and what is assumed by tersmus in its current
form, is to have each qualifier interpreted as a unary function, and
each non-logical connective as a binary function. This arguably makes
sense for all LAhE and JOI except {tu'a} and {ju'e}, but is a bit
strange for {NAhE bo}, and is marginal for {la'e} and {lu'e}, since the
referent-symbol relation isn't really bijective.

So relaxing that slightly, we can have qualifiers resp non-logical
connectives interpreted as binary resp ternary relations (which in many
cases are graphs of functions, but we don't require that). There's
a reasonably obvious choice for the relation in every case (even {fa'u},
if we're willing to clutter our universe up with a special data type to
handle it, which I think should be fine really).

So {LAhE ko'a} -> LAhE(x,ko'a), and we still have to decide how to
extract a term from this unary predicate. We have the usual options - we
can quantify (universally or existentially, plurally or singularly, with
various possibilities for the scope), we can take the mereological sum
of the extension (with or without a presupposition that this also
satisfies the predicate), we can take the kind, we can have the speaker
pick something(s) in the extension without further specification
(possibly with some restriction like it having to be somehow salient).
I think that's exhaustive (and so ta'o ru'e I think {lo} must be one of
these, or be ambiguous between some of them, cf bottom of this mail).

CLL lojban takes the quantification route. Based on the examples in CLL,
it looks like the implicit quantifier is {su'o}.

With xorlo, the natural choice is {lo}.

So this gets us (back) to {LAhE ko'a} -> {lo [LAhE] be ko'a}.
Maybe even {tu'a ko'a} can be put in that form.

Then there's the question of what to do with quantifiers and logically
connected sumti. Transparency is the simplest option, since it reduces
us directly to the case we've just dealt with, but it doesn't give the
desired semantics to {tu'a}. Sticking to the model described above, the
only alternative seems to be to have the logical operators operate on
the unary predicate, yielding e.g. {LAhE re da} -> {lo poi'i re da zo'u
LAhE be da}.

But this *still* doesn't give the desired semantics to {tu'a}.
So we give up on including {tu'a}, and handle it separately.

So finally, all we're left with is:
    1. defining the binary/ternary relation for each word;
    2. deciding between the two options for handling logical operators;
    3. deciding whether there should be any other exceptions.

1 is the business of a dictionary, not this thread.

I hope we can agree that the default for 3 should be "no" unless
there's a pressing reason.

For 2: either choice seems reasonable. I'd prefer transparency just
because it's simpler - but if you think, with {tu'a} entirely ignored,
that it's important to have opaqueness, then I'm happy to accept that.
Do you?

> > Regarding {lo}: could it be the "down" operator which extracts a kind
> > from a predicate? I'm not seeing any other options, if it is "definite"
> > and if \iota is out.
>=20
> That kind of presupposes that among all the various operators that
> linguists/logicians/etc have defined, described, explored there has to be
> one that matches "lo". I don't know enough about the subject to give an
> opinion one way or the other.

I intended no such presupposition. If it's something already named and
analysed, that makes things easier, but it isn't necessary. I really
honestly meant that I don't see what else {lo} could mean. In the
exhaustive-as-far-as-I-can-see list of plausible ways of extracting
a term from a unary predicate I gave above, if we rule out
quantification, require that the predicate determines the term
("definiteness"), and require that the resulting term satisfies the
predicate, then we're left with only these two possibilities:
    mereological sum of the extension with a presupposition that this
    satisfies the predicate (\iota)
or
    the kind corresponding to the predicate (down).

Am I missing some possibilities?

Martin

--yRA+Bmk8aPhU85Qt
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAlQ52EsACgkQULC7OLX7LNbgnQCfdjBsMpcShBldem6vjSwcZ+zV
8XAAn3PdiEJXzQ9WeBktHbBngUlC10qs
=m1Nv
-----END PGP SIGNATURE-----

--yRA+Bmk8aPhU85Qt--