Received-SPF: none (google.com: mbays@sdf.org does not designate permitted sender hosts) client-ip=192.94.73.24;
Date: Sun, 5 Oct 2014 19:49:58 -0400
From: Martin Bays <mbays@sdf.org>
To: lojban@googlegroups.com
Subject: Re: [lojban] Re: tersmu 0.2
Message-ID: <20141005234958.GD1974@gonzales>
References: <20140928013358.GB28734@gonzales>
 <CAO7tK2ds0RxZnHoUSodwty5hjWk+6hpKPj_Y8NoVy+paOc44sg@mail.gmail.com>
 <20140928152915.GB7320@gonzales>
 <CAO7tK2eST7Fj3qQa2DKrmfPP8pYQPToCQL7x7v8xWUqAn5FARQ@mail.gmail.com>
 <20141004141407.GG32481@gonzales>
 <CAO7tK2fS_pTD3snnSeQ4meDbrBhS_v8RCJvPvbEuLjXDhx-Drw@mail.gmail.com>
 <20141005153531.GA1974@gonzales>
 <CAO7tK2f_GVeDL5Qukx1k+3wTg5aVcY+z4W6JjB=hF1JGHzwwAw@mail.gmail.com>
 <20141005214350.GC1974@gonzales>
 <CAO7tK2fdDnOG5OSU5wJ=MQaDMroy3Ht45WjkMnCKBG1o9ofUTg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="KdquIMZPjGJQvRdI"
Content-Disposition: inline
In-Reply-To: <CAO7tK2fdDnOG5OSU5wJ=MQaDMroy3Ht45WjkMnCKBG1o9ofUTg@mail.gmail.com>
X-cunselcu'a-valsi: cumki
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: -


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

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

> On Sun, Oct 5, 2014 at 6:43 PM, Martin Bays <mbays@sdf.org> wrote:
> > * Sunday, 2014-10-05 at 14:10 -0300 - Jorge Llamb=EDas <jjllambias@gmai=
l.com>:
> > > I guess "li mo'e sumti-6 te'u lo'o" has to be equivalent to "sumti-6",
> > > but I don't know what happens when a quantifier or a logical
> > > connective gets involved. Maybe "li mo'e ci ko'a" =3D "lo ci ko'a", a=
nd
> > > "li mo'e ko'a .e ko'e" =3D "ko'a jo'u ko'e".
> >
> > I don't see how you get those. I get:
> >
> > broda li mo'e ko'a e ko'e ->
> >     (broda( ,[{ko'a}]) /\ broda( ,[{ko'e}]))
> >     ge broda li mo'e ko'a te'u lo'o gi broda li mo'e ko'e te'u lo'o
>=20
> That's assuming that "li mo'e ko'a .e ko'e" =3D "li mo'e ko'a je mo'e ko'=
e" =3D
> "li mo'e ko'a .e li mo'e ko'e".

The second one is a parse error, but yes, I have the other two being
equivalent. I wouldn't use anything like that as a derivation, though,
it's just that I have logical sumti connection working the same way
wherever the sumti occurs.

> That would mean, for example, that "li (expression)" does not always refer
> to the value of the expression but can be some operation transforming the
> bridi in which it occurs as an argument. My take is that sumti-6 is
> generally just a constant (or a function if it contains internally unbound
> variables). I'm not sure if that's the correct interpretation, but it see=
ms
> to be the simplest. (There are also some weird cases like "ko", "ma", and
> "zi'o" that need to be treated separately.)

My take is that sumti-6 indeed returns a term, but in the process of
parsing some logical operations may take effect. My way of thinking
about this is entangled with the details of the Haskell implementation
(monadic values), but I'll try to describe it in English!

So {ro da} returns the variable which subsequent {da} will return, but
it also causes a quantification; {ko'a .e ko'e} returns ko'a resp ko'e,
but it also causes a fork in processing, each side getting one of the
return values ko'a and ko'e, with the two sides then logically
connected. For this to make sense, you need a way of interpreting these
logical operations of quantification and connection. They apply in the
obvious ways to propositions and to predicates, and I think we agree
that this is how things work when parsing a sumti at main-bridi level or
within a description.

If I understand you correctly, you want special rules for what happens
when we parse a sumti with such logical information during the parsing
of a value: so rather than passing the actions of quantification and
connection up to the logic, they should be caught at the level of the
value and evaluated there. Right?

I imagine that could be made to work, but I worry that any such rules
for how the logical operations work on values would be rather arbitrary
and non-obvious. Having them pass up and operate in the usual logical
way seems much more natural to me.

Something analogous happens with sumtcita. Do you consider
    broda ca ro da
to mean something other than
    ro da zo'u broda ca da
(which is how tersmu currently handles it)?

> > > Uhoh.
> > So are you saying that {lo plise} *always* refers to Apple? Such that
> > it isn't really a matter of presuppositions after all, but rather of
> > ensuring our universes are equipped with kinds?
>=20
> I don't think so. What things are or are not in the universe of discourse
> is a matter of interpretation, and doesn't really affect the logical form.

OK, phew!

> The presupposition is that when you use "lo plise" there's something you
> are talking about, and that something is identified by their satisfying t=
he
> predicate "plise". Kinds may be one candidate interpretation, especially
> with so little context.

What is the logical content of this presupposition? Not actually
a matter of uniqueness, presumably? Some sort of maximality?

Martin

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

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

iEYEARECAAYFAlQx2SYACgkQULC7OLX7LNZP0ACdGuWf2KzvYJFxOwzo6OMiqg83
BWUAn0cRs+n8MQmuA8pTDMOYV5AlOIPp
=52AF
-----END PGP SIGNATURE-----

--KdquIMZPjGJQvRdI--