Received-SPF: none (google.com: mbays@sdf.org does not designate permitted sender hosts) client-ip=192.94.73.24;
Date: Tue, 21 Oct 2014 20:22:14 -0400
From: Martin Bays <mbays@sdf.org>
To: lojban@googlegroups.com
Subject: Re: [lojban] Re: tersmu 0.2
Message-ID: <20141022002214.GD25753@gonzales>
References: <20141015005542.GC3713@gonzales>
 <CAO7tK2cb-99yDWVYNN-yxCCXZsw=3t7O-aNbtd7rrhb5uTKq3w@mail.gmail.com>
 <20141018004531.GE20049@gonzales>
 <CAO7tK2c8JQsr+7zbrdos-9Wm1t8w+sH1SANSO6e_MGV4ZDjcow@mail.gmail.com>
 <20141018180946.GF20049@gonzales>
 <CAO7tK2dUSzYCWm+CNeNugkeU=aO6mWXSY3gn5dc+8XNU3GpasQ@mail.gmail.com>
 <20141018233648.GA29040@gonzales>
 <CAO7tK2eUqpe3AwAY-DxmONhxM3Pj5kyhTm605bAnD3iJEHVgug@mail.gmail.com>
 <20141021010639.GB11705@gonzales>
 <CAO7tK2c+ObFDqF_TZTQMjGJRZfZxpoY-pFB4_canWM3Lpdgvsw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="llIrKcgUOe3dCx0c"
Content-Disposition: inline
In-Reply-To: <CAO7tK2c+ObFDqF_TZTQMjGJRZfZxpoY-pFB4_canWM3Lpdgvsw@mail.gmail.com>
X-cunselcu'a-valsi: jdima
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: --


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

* Tuesday, 2014-10-21 at 19:16 -0300 - Jorge Llamb=EDas <jjllambias@gmail.c=
om>:

> On Mon, Oct 20, 2014 at 10:06 PM, Martin Bays <mbays@sdf.org> wrote:
> > * Saturday, 2014-10-18 at 22:27 -0300 - Jorge Llamb=EDas <jjllambias@gm=
ail.com>:
> Not sure what I meant now. I think I meant that you couldn't do with most
> functions (i.e. lo-functions) what you could do with the closed class of
> LAhE-functions, in terms of scope. (You can do it indirectly by using the
> prenex, of course.)

Ah, I see. Then yes, na'u aside.

> > But anyway: technically the class isn't actually closed, because of {na=
'u}!
>=20
> Would "na'u broda" be an open class of functions but not "lo broda"? "na'=
u"
> seems to be an inside-of-mex equivalent of "lo". We could say that "lo
> broda"=3D"li na'u broda mo'e zo'e/zi'o".

Plausibly.

> > {ro danlu cu jbena gi'e ba bo morsi}
> "ro danlu" has scope over "gi'e" so it would be:
>=20
> ro da poi danlu zo'u ge ge da jbena gi da morsi gi lo nu da morsi cu balvi
> lo nu da jbena

Good. Agreed (as far as the scope goes).

> > If the logical connective isn't {je}, probably the tag relation should
> > only apply when the connectands are both true, i.e. corresponding
> > events/facts occur/hold. This seems sensible, and is supported by CLL
> > Chapter 10 Verse 17.10.
>=20
> So ".i je nai [tag] bo" is always false?

I meant rather that it would be equivalent to ".i je nai bo".=20

> > Firstly, we need a way to assign an event/fact variable to a proposition
> > without changing its semantics. {fi'o du} lets us do this; {fi'o du ko'a
> > broda} means that broda occurs/holds and ko'a is equal to the
> > event/fact of this. Let's make this a primitive in the logic, writing it
> > as "=3D.", so e.g. "{ko'a}=3D. broda()". (So technically "[term]=3D." is
> > a modal operator.)
>=20
> I had never considered "fi'o du", it sounds useful. Maybe we want "fi'o
> ca'e du" if it's an assignment to a variable, rather than a claim. Or may=
be
> it should be "sei ca'e ko'a du'u no'a", although I'm not sure whether
> "no'a" gets the right bridi.

* Wednesday, 2014-10-22 at 00:30 +0200 - Ilmen <ilmen.pokebip@gmail.com>:
} I think you need {ca'e} for assigning a referent to {ko'a} (otherwise it
} would be an assertion "the bridi is identical to {ko'a}'s referent"), or
} whatever is the correct way to explicitly assign a referent to a
} pro-bridi without ambiguity.

I didn't really mean it to be an assignment in that sense, although
perhaps that could help. I did really mean that I want {fi'o du ko'a
broda} to occur/hold iff (broda occurs/holds and ko'a is the event/fact
of this).

(I think from now on I'll just say "occur" and "event"; depending on our
ontology of events, facts could just be special cases anyway - though
I don't know if we want to require that.)

} {fi'o} is maybe a little too vague for your purpose; I'd suggest {broda
} xoi <http://jbovlaste.lojban.org/dict/xoi> ke'a ca'e du fo'a} which
} would be semantically equivalent to {lo du'u broda ku ca'e du fo'a}, if
} I'm not mistaken.

Is {broda xoi xo'i [tag] ke'a} not equivalent to {[tag] broda}?

> > (I write the above paragraph as if I'm sure it makes sense, but I'm not.
> > If there are many events of brodaing in the situation, is {fi'o du ko'a
> > broda} true when ko'a is any of those events, or only when it's the
> > "intended" one?
>=20
> I would say it assigns to "ko'a" the intended ones, i.e. the ones you are
> describing with this proposition.

Plurally? Yes, that's another possibility. It would make things simpler
if we took a bridi to describe to a single event for the purposes of tag
handling (though of course allowing {lo mu nu limna} and so on).
I suppose we have to allow it to describe kinds of events too, if we're
to explain {roi} compositionally ({mu roi broda} -> "brodaing occurs
five times"). But I can't think of natural example where a plural
interpretation is necessary. Probably I'm just lacking imagination?

> Then we can handle tagged conjunction by quantifying over events:
> > ro danlu cu jbena gi'e ba bo morsi ->
> >     FA x1:(danlu(_)). EX x2. (x2=3D. jbena(x1) /\ (ba)(x2). morsi(x1))
> >     ro da poi ke'a danlu ku'o su'o de zo'u ge fi'o du de zo'u da jbena
> >     gi ba de zo'u da morsi
> > , which is I think a natural and useful way to interpret it.
> >
> > Now for connectives other than conjunction, I'm not seeing a neater
> > solution than to "skim off" the TT case (if there is one); so e.g. to
> > consider {broda .i na ja ba bo brode} to be equivalent to
> > { na broda .i ja broda .i je ba bo brode}, where the tagged conjunction
> > is interpreted as above.
> >
> > Not very pretty. I'd be happy to hear of alternative possibilities.
>=20
> The fact that it only works well with "je" suggests there's something wro=
ng
> with the "jek tag bo" construction.

I don't know, the "TT-skimming" semantics seem to give useful results in
at least some cases.

Probably most usefully, {broda na .i ja ba bo brode} would mean "if
broda, then afterwards brode".

Then there's the {ja} case I referred to in CLL, which seems reasonable.

For {jo}, it doesn't have an easy translation to english, but seems
plausibly useful anyway; e.g. {do ba prije gi'o ja'e bo snada} -> "you
will be wise and therefore successful, or neither".

> > It's odd however to have to read "li no pi'i mo'e ro namcu cu du li no"
> > > differently than "lo pilji be li no bei ro namcu cu du li no"
> >
> > Is it? I don't know.
> >
> > To analogise: I think the english pair
> > "zero times any number is equal to zero" and
> > "the product of zero and every number is equal to zero"
> > conveys the two meanings, using roughly the same structures.
>=20
> But that's purely due to the different scopes of any/every, not to the
> variation between times/product-of.  If you had "zero times every number =
is
> equal to zero" and "the product of zero and any number is equal to zero"
> you'd get the opposite result.

You're right for the second (a flexibility it would be nice for lojban
to have), but I think "zero times every number is equal to zero" is just
bad english; it can't have the opaque meaning. Which was my point.

Martin

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

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

iEYEARECAAYFAlRG+LYACgkQULC7OLX7LNZVHACgx0WOxzeUZC593yWtzyGLB0OU
CbQAn2yQz8YyZbIR6SlmUjtdkvEC1dxr
=m7X4
-----END PGP SIGNATURE-----

--llIrKcgUOe3dCx0c--