Received-SPF: none (google.com: mbays@sdf.org does not designate permitted sender hosts) client-ip=192.94.73.24;
Date: Tue, 7 Oct 2014 21:52:45 -0400
From: Martin Bays <mbays@sdf.org>
To: lojban@googlegroups.com
Subject: Re: [lojban] Re: tersmu 0.2
Message-ID: <20141008015245.GB17866@gonzales>
References: <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>
 <20141005234958.GD1974@gonzales>
 <CAO7tK2cr1GSJAsvyr_vCTPb_d-wwagdStfxA67NN4WbDzN80sw@mail.gmail.com>
 <20141006025048.GE1974@gonzales>
 <CAO7tK2fzy2Uz1sGBvX0WacV+uubGE5zugvKUi66m-LRrXAaYEQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="s2ZSL+KKDSLx8OML"
Content-Disposition: inline
In-Reply-To: <CAO7tK2fzy2Uz1sGBvX0WacV+uubGE5zugvKUi66m-LRrXAaYEQ@mail.gmail.com>
X-cunselcu'a-valsi: ratni
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: -


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

* Monday, 2014-10-06 at 18:33 -0300 - Jorge Llamb=EDas <jjllambias@gmail.co=
m>:

> On Sun, Oct 5, 2014 at 11:50 PM, Martin Bays <mbays@sdf.org> wrote:
> > * Sunday, 2014-10-05 at 22:33 -0300 - Jorge Llamb=EDas <jjllambias@gmai=
l.com
> > > Similarly for LAhE, which I take to be "lo broda be" for some suitable
> > > "broda".
> > Hmm, interesting. Yes, that does seem more useful.
> > Added to TODO!
>=20
> In addition to the unary functions (LAhE, NAhE BO), there's also the bina=
ry
> functions (JOI) which can be expanded as "lo broda be ... bei ..." for so=
me
> suitable "broda". These also should in principle be opaque to quantifiers
> and connectives, although the resulting forms are mostly useless.

Yes, they should all work the same way.

Thinking again, though, I'm not so convinced that having them work the
way you suggest is most useful.

Back in the situation with five apples, what would
    lu'i re plise
mean with your rules? It seems natural to want something definite, so it
literally being
    lo selcmi be re plise,
with {lo} having the maximality presupposition discussed elsewhere,
would be an answer. That presupposition in this case forces it to be
a kind; let's call it "sets of two apples". Is this really something we
want {lu'i} to be able to return?

This makes me uncomfortable.

At least {lu'i ro plise} and {lu'i ko'a .e ko'e} can still return sets
in the usual sense; but then with {ro} and {.e} there's no real need for
this rule that the logical operations are caught by the function, since
we can use plurals instead - with {lu'i lo ro plise} and {lu'i ko'a jo'u
ko'e} respectively.

Do you have examples where your rule gives useful results and where
there isn't an easy substitute using plurals?

> > With li-expressions I'm less sure, since I don't have a clear grasp of =
the
> > > interface between mekso and the ordinary part of the language. Is
> > > "cy du li cy" always true, for example?
> >
> > I don't think so. {cy} on its own is a sumbasti, probably referring some
> > lo cipni or similar. I think the mekso variable cy has to be entirely
> > separate to be of any use.
>=20
> So "li cy" is a free variable?  And bindable like "da": "ro li cy poi bro=
da
> zo'u li cy brode". So "ro li cy" is not "ro da poi me li cy"?

I certainly hope "ro li cy" is "ro da poi me li cy". Currently the only
exception to that is for the da-series, I think we'd need a very good
reason to add more.

I don't think there's an entirely direct way to quantify over mekso
variables, but how about e.g. {ro namcu goi li xy zo'u} (which I would take
to be an abbreviation of {ro da poi namcu ku'o da goi li xy zo'u})?

> "cy du li mo'e cy" should be true, however, because now "cy" is a sumti a=
nd
> not an operand. "li" and "mo'e" seem to be perfect inverses and cancel ea=
ch
> other out.

Agreed.

> I haven't really given it much thought, but I suppose I was thinking more
> as something like "lo se zei me be" than "lo du be". But yes, it makes
> sense that it would be something that is both one and two, which would on=
ly
> work in the case of "li pa .e ci" to refer to the cardinality of the Holy
> Trinity. (The way that was explained to me, it would not be an error but a
> divine mystery.)

Again, I'm not convinced this is useful enough to be a good idea.
I don't really see {li} as analogous to {lo}, so I think it's fine for
logical operators to work differently with the two. And in those cases
that we do want to catch the operators, we can always use {lo du be}:

{la ceicib zilkancu li pa .e ci} - false
{la ceicib zilkancu lo du be li pa .e ci} - mystery

> > Good. Sounds though like we might disagree on e.g.
> >     ca ja ba ro da broda
> > on which I get
> >     ga ro da ca da zo'u broda gi ro da ba da zo'u broda .
> > Would you get the quantifier having scope over the connective?
>=20
> I don't think I have any firm theory yet on the expansion of "ca ja ba". =
It
> could be as you say, or it could be that "ca ja ba" is "fi'o se cabna ja =
se
> balvi", in which case it would be:
>=20
> ca ja ba ro da broda
> =3D ro da se cabna ja se balvi lo nu broda

Yes, that's what I feared.

But CLL is quite explicit that logically connected tenses follow the
same expansion rules as logically connected sumti, and it seems entirely
coherent for them to, so I don't plan to change that without a good
reason.

> We do however sometimes say things like "pa roi ro mentu" for "once every
> minute", so at least in that case we seem to take the quantifier to have
> scope over the tag. I explain that by saying that "PA roi" is "fi'o te
> rapli be li PA" and thus PA is really a cardinality and not a quantifier.

I agree that the {pa} doesn't scope over the {ro}, if that's what you
mean. So {pa roi ro mentu zo'u} =3D=3D {ro da poi mentu ku'o pa roi da zo'u=
}.
"Once every minute" seems a feasible interpretation of that.

> > So you mean that {lo plise} has to refer to Apple *if* Apple is in the
> > UD, but for contextual reasons it sometimes might not be? But when it
> > isn't, there does nonetheless have to be a unique maximal referent, or
> > else {lo plise} fails to refer?
> >
>=20
> More or less, yes. The problem is that I don't have a good theory of UD, =
so
> "if Apple is in the UD" is extremely relative in practice, since it can
> very easily enter or leave the UD as required. For the analysis of logical
> forms we don't really need to concern ourselves with those things.

No, but we do need to put the maximality condition in there if it should
be there.

So... are we sure it should?

Both forms of the gadri seem useful to me. I have been happily using
{lo} without this maximality presupposition, and I think at least some
of the irci have been too.

But this goes a long way to explaining why you wanted {lo me ko'a gi'e
broda} for {ko'a poi broda}, where I thought having a maximality
condition would be more natural - you were understanding the maximality
to be implied by the {lo}!

Martin

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

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

iEYEARECAAYFAlQ0mO0ACgkQULC7OLX7LNZhmACgkuDSlB0xg6u+aRw7bKWkhALa
TPoAniv79A1burWZxl/KBE9UuxbRz+gA
=rRxm
-----END PGP SIGNATURE-----

--s2ZSL+KKDSLx8OML--