Received-SPF: none (google.com: mbays@sdf.org does not designate permitted sender hosts) client-ip=192.94.73.24;
Date: Sun, 12 Oct 2014 13:35:33 -0400
From: Martin Bays <mbays@sdf.org>
To: lojban@googlegroups.com
Subject: Re: [lojban] Re: tersmu 0.2
Message-ID: <20141012173533.GG23876@gonzales>
References: <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>
 <20141012012427.GF23876@gonzales>
 <CAO7tK2cFUJamcpRmv1y=Was0tUVrdaZrQ+B8_pVJ+rBd=JiJSQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="S5HS5MvDw4DmbRmb"
Content-Disposition: inline
In-Reply-To: <CAO7tK2cFUJamcpRmv1y=Was0tUVrdaZrQ+B8_pVJ+rBd=JiJSQ@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: -


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

* Sunday, 2014-10-12 at 11:10 -0300 - Jorge Llamb=EDas <jjllambias@gmail.co=
m>:

> On Sat, Oct 11, 2014 at 10:24 PM, Martin Bays <mbays@sdf.org> wrote:
>=20
> > 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},
>=20
> Why doesn't it make sense for "tu'a", is it because of the vague "co'e" or
> because of the embedding of its argument in a subordinate clause?
> It has a more complicated structure than most LAhE, and its precise
> meaning depends on context, but it is still a unary function, isn't
> it?

I was thinking of the {co'e}. Must {tu'a ko'a} refer to the same
abstraction every time it appears in a sentence? e.g. in {tu'a ko'a
rinka lo nu mi djica tu'a ko'a}? If not, we can't really model it as
a function.

> > 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.
>=20
> "cmima" is not bijective either, so if that was a requisite you'd have to
> include "lu'a" and "lu'i" among the marginals. which leaves only "lu'o" a=
nd
> "vu'i".

Well, I'm assuming {lu'a} is interpreted as the map which takes a set to
the unique plurality consisting of the set's elements (more
specifically, to the join aka mereological sum over the set), and does
the analogous thing for gunma, and {lu'i} maps a plurality X to the set
whose elements are the atoms of X. So those are functions in the sense
I meant.

> > 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).
>=20
> Can "ko'a fa'u ko'e prami vei ro fa'u su'o ko'i" be handled with a special
> data type?

Ah, good point.

ko'a fa'u ko'e prami vei ro fa'u su'o ko'i
-> vei ro fa'u su'o da poi me ko'i zo'u ko'a fa'u ko'e prami da

That can't be analysed by interpreting {ro fa'u su'o} as a generalised
quantifier in the usual sense, since counting da such that {ko'a fa'u
ko'e prami da} isn't the right thing. So we'd need to clutter up the
quantifiers too, and have special sorts for the corresponding variables.
Similarly we'd need to complicate the relations to handle {broda fa'u
brode}, and similarly tags, abstractors, operators, operands...

So yes, fa'u is probably best analysed as also being magic, and we
should ignore it for present purposes.

> > 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.
>=20
> "tu'a ko'a" could be "lo dumco'e be ko'a", but the problem is that "tu'a
> su'o ko'a" is supposed to be "lo du'u su'o ko'a co'e", which doesn't work
> with "dumco'e".

Right; I meant here only handling a simple sumti, i.e. just a term,
being what can be bound to ko'a. In terms of the grammar: a sumti6 which
isn't an unbound variable, and which isn't a qualified complex sumti if
qualifiers are transparent.

> > 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}.
>=20
> Sorry, which case?

Simple sumti.

> > 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}.
>=20
> I would call this one the simplest, the one that gives "lu'a ko'a .e ko'e"
> =3D "lo cmima be ko'a .e ko'e" rather than "lo cmima be ko'a ku .e lo cmi=
ma
> be ko'e".

Here's why transparency seems simplest to me: once we ignore exceptions
like {tu'a}, and assuming definiteness of {lo}, and considering only
simple sumti, what we've done by defining a binary relation and then
hitting it with {lo} is actually to define a unary function. So we
*could* decide at this point that we're back with the simplest semantics
where each qualifier is interpreted as a unary function; we've just
given a slightly baroque explanation for what that unary function is.
Since in most cases there's a clear choice for the function which
doesn't need {lo} to explain it, this seems very natural to me.

If we think that way, hiding the step with {lo}, transparency is the
only option - because there's no longer a subbridi in sight.

> 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.

> "fa'u" and "ju'e" are exceptions in an opposite sense than "tu'a". Whereas
> "tu'a" constrains the bridi-operators that it takes as arguments to act on
> a subordinate predicate, "fa'u" and "ju'e" are themselves bridi operators
> that act on a superordinate bridi.

I see that for fa'u. Why for ju'e? What does it do?

> > 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?
>=20
> I don't agree transparency is simpler.
>=20
> Also, to give an argument of the kind that And would disapprove of, I thi=
nk
> that as a general rule sumti-6 should not be bridi operators, and since
> LAhE is in sumti-6, it should generate a logical term, not a pseudo-term.

I'm probably more swayed by this kind of argument than I should be, but
it would indeed be nice for unbound variables to be the only
exception...

(well actually {ma} is something of an exception too, but in a quite
different way)

> This argument doesn't apply to JOI, which shows up higher up in the gramm=
ar.

Interesting point... but I still feel JOI should be opaque if LAhE is.

This has knock-on effects elsewhere, by the way. Currently I have e.g.
{pu je ca bi'o ba nolraitru} <->
    {pu bi'o ba nolraitru .i je ca bi'o ba nolraitru}
which fits with transparency for non-logical connectives on sumti.
I don't really know if this is right. Same story for operators (but not
for tanru connectives).

> > > > Regarding {lo}:
> > 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?
>=20
> If one of these operators gives reasonable meanings to all of these
> sentences, I would say go for it:
>=20
>  lo ci cukta poi mi tcidu ca lo ca masti cu cpana lo vi jubme

Right, I'd say this rules out "down" - that predicate is far too
specific to sensibly have a kind attached, I think.

>  mi nelci lo ka limna
>=20
>  mi ca'o pinxe lo djacu
>
>  lo djacu cu dunja lo ka kelvo li no
>
>  lo cipni cu se farvi lo dinsauru

Should a kind reading be available even if we're in the process of
talking about instances? Even if they're used elsewhere in the sentence?
e.g. is this legitimate, where kinds are intended only within the du'u:

lo djacu cu ba zi spojygau lo botpi noi dy nenri ku ri'a lo du'u ge lo
djacu cu dunja lo ka kelvo li no gi lo sligu djacu cu denmi mleca lo
litki djacu

? If not, maybe \iota is the right thing after all.

Or would you allow this, but only because of a domain shift within the
du'u (so it wouldn't be allowed if both {lo djacu} were at main bridi
level)?

Martin

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

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

iEYEARECAAYFAlQ6u+UACgkQULC7OLX7LNaszwCcDv1pXv0XOGvjQuQWJ9j66jRC
iUoAoOkIr1OWPvbVfYyOTwaHlEUOkr+J
=7VD/
-----END PGP SIGNATURE-----

--S5HS5MvDw4DmbRmb--