Received-SPF: none (google.com: mbays@sdf.org does not designate permitted sender hosts) client-ip=192.94.73.24;
Date: Fri, 17 Oct 2014 20:45:31 -0400
From: Martin Bays <mbays@sdf.org>
To: lojban@googlegroups.com
Subject: Re: [lojban] Re: tersmu 0.2
Message-ID: <20141018004531.GE20049@gonzales>
References: <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>
 <20141015005542.GC3713@gonzales>
 <CAO7tK2cb-99yDWVYNN-yxCCXZsw=3t7O-aNbtd7rrhb5uTKq3w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="CGDBiGfvSTbxKZlW"
Content-Disposition: inline
In-Reply-To: <CAO7tK2cb-99yDWVYNN-yxCCXZsw=3t7O-aNbtd7rrhb5uTKq3w@mail.gmail.com>
X-cunselcu'a-valsi: xampo
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: -2.6 (--)
X-Spam_score: -2.6
X-Spam_score_int: -25
X-Spam_bar: --


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

* Wednesday, 2014-10-15 at 18:07 -0300 - Jorge Llamb=EDas <jjllambias@gmail=
=2Ecom>:

> On Tue, Oct 14, 2014 at 9:55 PM, Martin Bays <mbays@sdf.org> wrote:
> > 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.
>=20
> Yes, but that rule doesn't automatically apply to all constructs. You
> can't for example apply it directly to "lo broda be ko'a .e ko'e cu
> brode". Therefore it is effectively a separate rule for each construct
> it applies to.

I don't see it that way at all. It's the same rule. It's just that the
rule is applying to the implicit sub-bridi of the description clause; in
general it applies to the immediately enclosing bridi (just like any
other bridi operator, e.g. tenses).

(I'm not particularly happy with this "bridi" and "sub-bridi"
terminology, btw, though I hope you can see what I mean by it; feel free
to suggest alternatives)

> > 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.
>=20
> LE [quantifier] [sumti] is interesting. I think I never actually gave
> much thought to "lo re lo mlatu .e ci lo gerku" having such a very
> unintuitive parse.

So it does... I guess to get the "lo (re lo mlatu .e ci lo gerku)", you
have to use
    lo tu'o boi re lo mlatu .e ci lo gerku
?

> In any case, I wouldn't introduce an additional rule to interpret "lo ci
> ko'a .a ko'e":
>=20
> lo ci ko'a .a ko'e
> =3Dlo poi'i ci mei gi'e me ko'a .a ko'e
> =3Dlo poi'i ci mei gi'e ga me ko'a gi me ko'e
>=20
> I assume you are not interpreting it in that way, but rather as "lo ci ko=
'a
> ku .a lo ci ko'e"?

Yes, pretty much.

> For "me [sumti]", the predicate "menre" was proposed, such that "me
> [sumti]" =3D "menre (be) [sumti]". "me ko'a .e ko'e" doesn't require a new
> rule since:
>=20
> me ko'a .e ko'e
> =3D menre ko'a .e ko'e
> =3D ge menre ko'a gi menre ko'e
> =3D ge me ko'a gi me ko'e

Yes, good. Though as mentioned elsewhere in the thread, this doesn't
necessarily mean that the two rules are entirely equivalent - it depends
on what if any extra baggage comes with an implicit sub-bridi.

> I have no idea what the rules for mekso are in detail, so I don't know
> whether for example "li na'u sinso mo'e ko'a .e ko'e" is supposed to be
> equivalent to "lo sinso be ko'a .e ko'e" or to "li na'u sinso mo'e ko'a
> lo'o .e li na'u sinso mo'e ko'e". I would like to say (not too adamantly)
> that it's the first, which doesn't require an additional rule for ".e", b=
ut
> you are probably interpreting as the second.

I am, which doesn't require an additional rule for ".e" ;)

But actually, I don't understand that example. What is the operand
{mo'e ko'a .e ko'e} such that sine of it is something which is sine of
both ko'a and ko'e?

> > > 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".
>=20
> I suppose that's one choice, although it's not a necessity that
> juxtaposition be equated with conjunction, or that the negation of two
> separate propositions has to be the negation of their conjunction.

Is there a plausible alternative?

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

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

iEYEARECAAYFAlRBuCsACgkQULC7OLX7LNaedQCeNKMq0weru/U1qytXaI4+cMNR
9XwAn0tJodkPVDVnKEuLGJGB1pBU2KIk
=bj9H
-----END PGP SIGNATURE-----

--CGDBiGfvSTbxKZlW--