Received-SPF: none (google.com: mbays@sdf.org does not designate permitted sender hosts) client-ip=192.94.73.24;
Date: Fri, 10 Oct 2014 19:40:48 -0400
From: Martin Bays <mbays@sdf.org>
To: lojban@googlegroups.com
Subject: Re: [lojban] Re: tersmu 0.2
Message-ID: <20141010234033.GG22868@gonzales>
References: <20141005234958.GD1974@gonzales>
 <CAO7tK2cr1GSJAsvyr_vCTPb_d-wwagdStfxA67NN4WbDzN80sw@mail.gmail.com>
 <20141006025048.GE1974@gonzales>
 <CAO7tK2fzy2Uz1sGBvX0WacV+uubGE5zugvKUi66m-LRrXAaYEQ@mail.gmail.com>
 <20141008015245.GB17866@gonzales>
 <CAO7tK2fokLXQ3queR+jP88xaoxMPQBQUojsAOZrF49hKTY=-LQ@mail.gmail.com>
 <20141009010533.GF18854@gonzales>
 <CAO7tK2erLDXJy5jOAx7--+vamH9brWJNSH2K82ACJgKbDVvD8g@mail.gmail.com>
 <20141009233031.GC1592@gonzales>
 <CAO7tK2cpdLRm8AOtHjADMKMP10uFu_N4mfddsP0-q07YnFzSLA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="IbVRjBtIbJdbeK1C"
Content-Disposition: inline
In-Reply-To: <CAO7tK2cpdLRm8AOtHjADMKMP10uFu_N4mfddsP0-q07YnFzSLA@mail.gmail.com>
X-cunselcu'a-valsi: vanbi
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: -


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

* Thursday, 2014-10-09 at 22:04 -0300 - Jorge Llamb=EDas <jjllambias@gmail.=
com>:

> On Thu, Oct 9, 2014 at 8:30 PM, Martin Bays <mbays@sdf.org> wrote:
>=20
> > Anyway. Regarding whether sumti qualifiers and non-logical connectives
> > should be transparent or opaque: there doesn't seem to be a clear
> > argument either way based on utility. The transparent option is simpler
> > and results in clear meanings in all cases, so doesn't it make sense to
> > go for that?
>=20
> For me there's no doubt that for LAhE/NAhE BO it has to be opaque. I don't
> have a strong opinion on JOI, but I would want to make it opaque just by
> analogy.

OK. I don't really understand why opaqueness is so clearly preferable
- but perhaps this is a matter of wisdom born from years of usage, which
I shouldn't expect to understand.

Anyway, let me try to understand exactly what the opaque semantics
should be.

Let's stick with sumti qualifiers for simplicity. I understand you as
having each correspond to a binary relation, with then e.g. {tu'a ko'a}
translating to
    \iota x. {tu'a}(x,ko'a)
(writing "{tu'a}(x,y)" for the binary relation, and using the iota
notation discussed below, which I've rewritten here in a more
conventional logical notation; "\iota x. \phi(x)" is a term referring to
the largest (=3D=3D unique maximal) x such that \phi(x).)

Then opaqueness means that logical operators apply within the \iota, so
e.g. {tu'a ko'a .a ko'e} -> \iota x. ({tu'a}(x,ko'a) \/ {tu'a}(x,ko'e))
and {tu'a re da} -> \iota x. EQ(2) y. {tu'a}(x,y)
(where EQ(2) is the "exactly 2" quantifier (also written \exists^{=3D2})).

Now at least sometimes, we seem forced into a kind reading of the iota;
e.g. if {tu'a}(x,y) means something like "x is an abstraction involving
y", then in {broda tu'a ko'a .e ko'e} we seem forced to a kind reading:
"abstractions involving ko'a and involving ko'e".

But then I run into a problem with the next obvious example. assuming
{na'e bo}(x,y) is disjointness, which I'll write as (x/\y)=3D=3D0 (where at
least for plurals, this is {no da me xy gi'e me ybu}),

    na'e bo ko'a e ko'e broda
    -> broda(\iota x. ({na'e bo}(x,ko'a) /\ {na'e bo}(x,ko'e)))
    -> broda(\iota x. ((x /\ ko'a) =3D=3D 0 /\ (x /\ ko'e) =3D=3D 0))

Now we seem to have a problem. There seem to be two feasible options for
the largest thing disjoint from ko'a and ko'e: it could be the plural
"everything but ko'a and ko'e", but it could also be the kind "things
disjoint from ko'a and from ko'e". This isn't actually anything to do
with opaqueness; the same thing happens just with {na'e bo ko'a}.

Example where both readings are actually plausible:
    mi xebni na'e bo mi
could mean either "I hate everything other than me" or "I hate things
other than me".

So maybe {lo} =3D=3D \iota =3D=3D "the largest" isn't really right after al=
l?

> > Meanwhile, regarding the "maximality presupposition" of {lo}, I wanted
> > to bring up again Cherchia's version of the Frege-Russel iota. Quoting
> > from Chiercha "Reference to kinds across languages" 1998:
> > \iota X =3D the largest member of X if there is one (else, undefined).
> > (where "largest" is with respect to AMONG).
> >
> > So {lo broda} refers to \iota of the extension of broda(_), with the
> > presupposition that this is defined?
> >
> > So rather than representing {lo broda cu brode} as
> >     Presupposition: broda(c1)
> >     brode(c1)
> > could we then just represent it as
> >     brode(\iota broda(_))?
> >
> > That would make me happy.
>=20
> How would you express it in Lojban?

As {lo broda cu brode}!

\iota x. P(x)  <->  lo poi'i P
is what I was hoping for.

> (Hopefully nothing involving mekso. :)

{li mo'e lo nu'a na'u broda} does have a certain ring to it, now you
mention it...

Martin

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

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

iEYEARECAAYFAlQ4bnEACgkQULC7OLX7LNYR7QCgqtDzO5RHIrREND06obKsd4sz
z8AAnivQKZabO2cdVvEvNZIGyG6/aj4z
=rwwY
-----END PGP SIGNATURE-----

--IbVRjBtIbJdbeK1C--