Received-SPF: none (google.com: mbays@sdf.org does not designate permitted sender hosts) client-ip=192.94.73.24;
Date: Sat, 4 Oct 2014 10:35:43 -0400
From: Martin Bays <mbays@sdf.org>
To: lojban@googlegroups.com
Subject: Re: [lojban] Re: {da poi} (was: Re: tersmu 0.2
Message-ID: <20141004143543.GI32481@gonzales>
References: <CACf3dPniWPENbiHT=EsTHGTApOOx5duQgo5SxZevF=FM7jUnqg@mail.gmail.com>
 <CACf3dPnptiNra7pU3dyuC7-Mhm-T6_mpyP92SNs1GXy+Roo+dw@mail.gmail.com>
 <20140928160229.GD28734@gonzales>
 <CACf3dPnGDFq5WKGzOY_yBejZ3N94biNgR5abSFBnSOehfO+-Gg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="PyMzGVE0NRonI6bs"
Content-Disposition: inline
In-Reply-To: <CACf3dPnGDFq5WKGzOY_yBejZ3N94biNgR5abSFBnSOehfO+-Gg@mail.gmail.com>
X-cunselcu'a-valsi: gunka
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: -


--PyMzGVE0NRonI6bs
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

* Sunday, 2014-09-28 at 20:17 +0100 - And Rosta <and.rosta@gmail.com>:

> On 28 Sep 2014 17:03, "Martin Bays" <mbays@sdf.org> wrote:
> > * Sunday, 2014-09-28 at 12:35 +0100 - And Rosta <and.rosta@gmail.com>:
> > > On 28 Sep 2014 12:04,and.rosta@gmail.comwrote:
> > > > On 28 Sep 2014 02:34, "Martin Bays" <mbays@sdf.org> wrote:
> > > > > the compositionality of restrictive clauses (which admittedly is
> > > > > already broken in some other cases, e.g. {da poi broda}).
> > > >
> > > > I agree {da poi} looks broken. What are the remedies? (1) To
> > > > allow noncompositional idioms? (2) To define /poi/ as an
> > > > allomorph of /noi/ in this syntactic environment? (3) To accept
> > > > that, given the internal logic of the language, {da poi} as
> > > > habitually used is simply wrong? (4) To seek and find
> > > > a consistent definition for {poi} and {noi} such that {da poi}
> > > > usage becomes correct?
> > (5) change the grammar to match the semantics, taking variable out of
> > sumti6, and having restrictive relatives allowed only where there's
> > a matching place for a quantifier;
> > (6) note that doing (5) wouldn't actually render anything ungrammatical,
> > so treat the existing grammar as a kind of shorthand for that in (5),
> > and so consider current handling to be "effectively compositional".
>=20
> If {X poi broda cu brode} =3D {lo me X gi'e broda cu brode} and {X noi br=
oda
> cu brode} =3D {X broda gi'e ...... brode}, then neither strike me as
> appropriate for restricted quantification.

Agreed.

> To get at the underlying logic
> of {so'e broda cu brode}, it seems to me you need something like {lo du'u
> ke'a broda kei so'e zei so'e lo du'u ke'a brode}, where {so'e zei so'e} is
> an ad hoc selbri counterpart of so'e, and which xorxes would surely want =
to
> simplify to {lo broda cu so'e zei so'e lo brode}. (This is similar to but
> less adequate than the solution I got introduced into Xorban.)
>=20
> So if there is a compositional interpretation for {da poi}, can you gently
> and not too technically spell it out for me?

Sorry, I wasn't trying to claim one in that sense. All I meant was that
we can consider the semantics to be compositional where one of the
components is "quantifier? variable restrictive-relatives?", and another
separate component is "quantifier? sumti6 restrictive-relatives?", where
we give these the (different) semantics discussed.

In other words, I proposed cheating!

> > > Modifying a variable, that cannot be the difference. I had been
> > > assuming that noi modifying a variable would have outermost scopal
> > > position within the domain in which the variable is bound.
> >
> > Hmm, that makes some sense. I have been taking, ever since xorxes told
> > me off for doing otherwise in the first release, incidentals to be
> > truly incidental, having no effect on the truth value of the main
> > proposition. So a {noi} on a variable yields a side claim entirely
> > outside the scope of the corresponding quantifier, so involving an
> > unbound variable, which I'm currently (fairly arbitrarily) handling by
> > universally quantifying it out over whatever domain it was originally
> > quantified over, so e.g. {du su'o da poi broda zi'e noi brode} -> {ro da
> > poi broda zo'u da brode .i su'o da poi broda zo'u du da}.
>=20
> It seems to me that my suggestion better yields a single rule that applies
> consistently to all cases. E.g. {ro broda  noi brodo na brode} =3D {ro br=
oda
> ku brodo gi'e na brode}.

So e.g. {naku ro broda noi brodo na brode} =3D {naku ro broda ku brodo
gi'e na brode} =3D=3D {su'o broda ga na brodo gi brode}?
Having fully scope-breaking incidentals seems more useful.

Martin

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

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

iEYEARECAAYFAlQwBb8ACgkQULC7OLX7LNaKOwCfQDehyMC36uAJOngR3BYL/O8I
cLQAn1ldMix6oaqpwO+tyqCPyqZSKoRW
=7gbz
-----END PGP SIGNATURE-----

--PyMzGVE0NRonI6bs--