Received-SPF: none (google.com: mbays@sdf.org does not designate permitted sender hosts) client-ip=192.94.73.24;
Date: Tue, 14 Oct 2014 20:55:42 -0400
From: Martin Bays <mbays@sdf.org>
To: lojban@googlegroups.com
Subject: Re: [lojban] Re: tersmu 0.2
Message-ID: <20141015005542.GC3713@gonzales>
References: <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>
 <20141012173533.GG23876@gonzales>
 <CAO7tK2d7nJEczJ7jzMLZBCzUB3ODu42v7Lp0SmsYTYc113r4RQ@mail.gmail.com>
 <20141014010742.GF19061@gonzales>
 <CAO7tK2fVs8r0cbk_Cvu_TgAf19QA19fmqEFCFbQ=mROqpFvd-Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="8X7/QrJGcKSMr1RN"
Content-Disposition: inline
In-Reply-To: <CAO7tK2fVs8r0cbk_Cvu_TgAf19QA19fmqEFCFbQ=mROqpFvd-Q@mail.gmail.com>
X-cunselcu'a-valsi: murse
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: -


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

* Tuesday, 2014-10-14 at 18:30 -0300 - Jorge Llamb=EDas <jjllambias@gmail.c=
om>:

> On Mon, Oct 13, 2014 at 10:07 PM, Martin Bays <mbays@sdf.org> wrote:
>=20
> > I see what you mean, and I agree it's a worthwhile exercise to express
> > the final logical form in lojban using as few constructs as possible;
> > but I don't see why this should be done greedily, i.e. first translating
> > to minimalistic lojban and then finding the logical form.
>=20
> Just economy of rules I suppose.
>=20
> We already have a rule to interpret the sumti created with ".e" when it is
> used as an argument of a predicate. We can use this same rule if we
> interpret LAhE in terms of a predicate. If not, we need a separate rule f=
or
> how to interpret the sumti created with ".e" when used as the argument of=
 a
> LAhE.

But the rule for logically connected sumti at top level is the same rule
as for logical connectives in various other places, e.g. bridi tails,
abstractions, tags, operators, operands. Roughly, that rule is: you
substitute in each of the connected possibilities, yielding two
propositions, then logically connect those propositions.

Probably I shouldn't start talking in code, but I can't resist
indicating just how natural the transparent semantics look from the
perspective of the algorithm tersmu is using. Currently the relevant
code is just this oneliner:
    QualifiedSumti qual _ s -> QualifiedTerm qual <$> parseSumti s
which roughly says:
    "to parse a qualified sumti: parse the underlying sumti, and qualify
    the resulting term.".
This implements transparency, because if s is a logically connected
sumti, then "parseSumti s" executes the standard connective rule
("doConnective", the same thing that's used for tense connection,
operand connection, etc; 8 places in the code in all) - this effectively
forks processing, substituting each of the two connected sumti and
obtaining propositions for each, then logically connecting those
propositions.

There are by the way a few places other than top-level where a sumti can
occur: {me [sumti]}, {mo'e [sumti]}, and in sumti tails,
e.g. {LE [quantifier] [sumti]}. If we wanted to always reduce to the
case of the sumti being directly an argument of a predicate, then we'd
need to introduce predicates for these too.

For sumti-tail there's an obvious choice: {lo [quantifier] [sumti]}
could be equivalent to {lo [quantifier] me [sumti]} for complex sumti as
well as for simple sumti.

For {me}, I'm not sure... is there something {ko'a me ko'e .e ko'i}
could mean other than {ko'a me ko'e .i je ko'a me ko'i}?

As for {mo'e}, I suppose we could use a relation "is the value
corresponding to"? But it really does seem to me much simpler to just
have {mo'e ko'a .e ko'e} be equivalent to {mo'e ko'a .e mo'e ko'e}.

> > In isolation, I don't see a difference between
> >     broda .i brode
> > and
> >     broda .i je brode
> >
> > There are differences once other constructs get involved, but I don't
> > see how to use that to differentiate between {ju'e} and {e} as sumti
> > connectives.
>=20
> Do we even know what "na ku zo'u broda .i bo brode" means?

I believe it's the same as "na ku ge broda gi brode".

> > kukte [fa] lo plise .e re lo ci plise noi vi zvati
> >
> > The idea here is to force some individual apples into the domain, so if
> > {lo} is really \iota then {lo plise} can't refer to the kind.
>=20
> I suppose if "lo" was \iota and you don't allow the universe of discourse
> to change then the sentence must be contradictory. But I have no problem
> reading it as something like "apples, and two of these three in particula=
r,
> are delicious". Maybe more explicitly, for when we tackle UI:
>=20
>  kukte fa lo plise .e su'a nai re lo ci plise noi vi zvati

OK, I think that does rule out \iota! If domain shifting were allowed
within a single proposition like that, we'd need to find a new way to
understand quantifiers, and the sky would generally fall in.

So maybe {lo} isn't quite \iota, but it's something like "\iota applied
to some ad-hoc but somehow natural subset of the extension"? If that
isn't to reduce to just "lo broda is something(s) satisfying broda",
this "natural" will have to be doing a lot of work... I don't have much
of an idea what it could be.

Possibly it can all be done by specifying the tense and aspect of
{broda}? With the kind reading corresponding to gnomic aspect?

Martin

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

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

iEYEARECAAYFAlQ9xg4ACgkQULC7OLX7LNaJDwCfXrvpMjcN6QAinQEiQ6rN9XaI
RU8An2cqgm1P2dTq+cY60Z/V7C2MiBuT
=8HdH
-----END PGP SIGNATURE-----

--8X7/QrJGcKSMr1RN--