Received: from mail-pz0-f61.google.com ([209.85.210.61]:55040)
	by stodi.digitalkingdom.org with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76)
	(envelope-from <lojban+bncCOTEtqyUDhCx2Oj0BBoExNCIuQ@googlegroups.com>)
	id 1RFF3i-0004W0-89; Sat, 15 Oct 2011 17:58:42 -0700
Received: by pzk4 with SMTP id 4sf1547712pzk.16
        for <multiple recipients>; Sat, 15 Oct 2011 17:58:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=beta;
        h=x-beenthere:received-spf:date:from:to:subject:message-id:references
         :mime-version:content-type:content-disposition:in-reply-to:x-pgp-key
         :x-pgp-keyid:x-cunselcu'a-valsi:user-agent:x-original-sender
         :x-original-authentication-results:reply-to:precedence:mailing-list
         :list-id:x-google-group-id:list-post:list-help:list-archive:sender
         :list-subscribe:list-unsubscribe;
        bh=e3XGEWPyGn9gz/IaVuHpzZoi1zcP2SW6zLviJ2kynuc=;
        b=sH1BuJtSBwxrBAWsaOgYFedZm5tQs/FgWFVAf4bc63GgX1YmiqjEi8uQd32gdrUWmk
         Oz/lpzAaiUiVtOtY9qSndfo9k4ssdi+aFFE9zxXGx3Q/qkkDJdduJcJWpsP6LzwQ1O+h
         DVtaEiyQRYZUmbjQOvdUmo3XRKDjCCRgSxGBY=
Received: by 10.68.29.106 with SMTP id j10mr2814938pbh.6.1318726705266;
        Sat, 15 Oct 2011 17:58:25 -0700 (PDT)
X-BeenThere: lojban@googlegroups.com
Received: by 10.68.42.97 with SMTP id n1ls14141972pbl.2.gmail; Sat, 15 Oct
 2011 17:58:24 -0700 (PDT)
Received: by 10.68.8.229 with SMTP id u5mr19557792pba.0.1318726704736;
        Sat, 15 Oct 2011 17:58:24 -0700 (PDT)
Received: by 10.68.8.229 with SMTP id u5mr19557791pba.0.1318726704722;
        Sat, 15 Oct 2011 17:58:24 -0700 (PDT)
Received: from sdf.lonestar.org (mx.sdf.org. [192.94.73.19])
        by gmr-mx.google.com with ESMTPS id r5si14037236pbe.1.2011.10.15.17.58.24
        (version=TLSv1/SSLv3 cipher=OTHER);
        Sat, 15 Oct 2011 17:58:24 -0700 (PDT)
Received-SPF: pass (google.com: best guess record for domain of mbays@sdf.org designates 192.94.73.19 as permitted sender) client-ip=192.94.73.19;
Received: from gonzales.homelinux.org (root@sverige.freeshell.org [192.94.73.4])
	by sdf.lonestar.org (8.14.5/8.14.3) with ESMTP id p9G0wOwc010668
	for <lojban@googlegroups.com>; Sun, 16 Oct 2011 00:58:24 GMT
Received: from martin by gonzales.homelinux.org with local (Exim 4.75)
	(envelope-from <mbays@sdf.org>)
	id 1RFF3X-0006TQ-I5
	for lojban@googlegroups.com; Sat, 15 Oct 2011 20:58:23 -0400
Date: Sat, 15 Oct 2011 20:58:23 -0400
From: Martin Bays <mbays@sdf.org>
To: lojban@googlegroups.com
Subject: Re: [lojban] {zo'e} as close-scope existentially quantified plural variable
Message-ID: <20111016005823.GJ3779@gonzales>
References: <20111015155009.GA5916@gonzales>
 <CAO7tK2eT3xjSf7-aBuWGeMj2ck+pGAU8ooXk+xa4eUiVypBW4g@mail.gmail.com>
 <20111015185726.GC3779@gonzales>
 <CAO7tK2eeraqkbBT20+vuRoL53TtcuT6VMaNFE=iFa23Ck=5zRw@mail.gmail.com>
 <20111015203444.GD3779@gonzales>
 <CAO7tK2c70-nJ3hM6=h_wp4RmLnaoL7i8ZsYFvOb2WGxvx7MCtg@mail.gmail.com>
 <20111015221511.GF3779@gonzales>
 <CAO7tK2eRQ5inZWirzh-OGSy+weqC308fiekOZTVTmr+qQQaFJw@mail.gmail.com>
 <20111015232240.GG3779@gonzales>
 <CAO7tK2dac=GeXUVS=Tw9qqZznui7hc6_AgRwS5d8WdhjnLY0VA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="ofZMSlrAVk9bLeVm"
Content-Disposition: inline
In-Reply-To: <CAO7tK2dac=GeXUVS=Tw9qqZznui7hc6_AgRwS5d8WdhjnLY0VA@mail.gmail.com>
X-PGP-Key: http://mbays.freeshell.org/pubkey.asc
X-PGP-KeyId: B5FB2CD6
X-cunselcu'a-valsi: kenra
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Original-Sender: mbays@sdf.org
X-Original-Authentication-Results: gmr-mx.google.com; spf=pass (google.com:
 best guess record for domain of mbays@sdf.org designates 192.94.73.19 as
 permitted sender) 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?hl=en_US>, <mailto:lojban@googlegroups.com>
List-Help: <http://groups.google.com/support/?hl=en_US>, <mailto:lojban+help@googlegroups.com>
List-Archive: <http://groups.google.com/group/lojban?hl=en_US>
Sender: lojban@googlegroups.com
List-Subscribe: <http://groups.google.com/group/lojban/subscribe?hl=en_US>, <mailto:lojban+subscribe@googlegroups.com>
List-Unsubscribe: <http://groups.google.com/group/lojban/subscribe?hl=en_US>, <mailto:lojban+unsubscribe@googlegroups.com>
X-Spam-Score: -0.0 (/)
X-Spam_score: -0.0
X-Spam_score_int: 0
X-Spam_bar: /


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

* Saturday, 2011-10-15 at 20:52 -0300 - Jorge Llamb=EDas <jjllambias@gmail.=
com>:

> On Sat, Oct 15, 2011 at 8:22 PM, Martin Bays <mbays@sdf.org> wrote:
> >> (In fact I'm never quite sure about what to do with "poi" when it is
> >> not being used to restrict the domain of a quantifier.)
> >
> > Quite. If it does do anything, there's also the issue of which gets
> > priority in {ro lo broda poi brode}.
>=20
> Does it make an actual difference? "ro lo broda poi brode" =3D "ro da
> poi me lo broda zi'e poi brode".

It does make a difference if {ro} is a singular quantifier.

{ro ko'a poi broda cu brode} -> "for every atom x among the (plural)
referent of {ko'a} such that broda(x), brode(x)"

So (forgetting about kinds for a minute, since this is purely an issue
of plural semantics) in {ro lo broda poi ke'a brode}, the question is
whether the relative clause is evaluated with a potential plural
referent of {lo broda} for {ke'a}, or whether it's evaluated once per
atom below the plural referent of {lo broda}, with that atom for {ke'a}.

I think the latter does make most sense.

> > It could *suggest* that the {lo xasli} should be interpreted more
> > specifically, I suppose, but I don't see why it should do so any
> > more than the {noi} clause.
>=20
> "noi" makes perfect sense when applied to a singleton. "poi", while
> still interpretable, doesn't make that much sense because the only
> thing a singelton could be restricted to is itself, so no real
> restriction. It's the same situation that occurs with quantifiers: you
> can quantify over a singleton, but since doing so is rather pointless,
> the mere presence of a quantifier suggests the domain should not be a
> singleton.

So you mean {lo xasli poi da darxi} gets interpreted as {su'o lo xasli
poi da darxi} (interpreted according to the second of the two options
above)? That seems reasonable.

Or maybe as {pi za'u lo xasli poi da darxi} (assuming that {pi za'u}
is a plural existential quantifier), which maybe is even more
reasonable.

> >> "lo speni be da" is "zo'e noi speni da". I don't see how you could get
> >> rid of the unbound variable there. There's no referential "lo speni"
> >> in the non-referential "lo speni be da".
> >
> > OK, but if {lo speni be da} =3D=3D {zo'e noi speni da}, then we have
> > a situation analogous to that above - with {zo'e} in place of {lo
> > xasli}. {zo'e} can be taken to referential, for example with referent
> > the kind 'humans', which does indeed satisfy {ke'a speni da} for each
> > da.
> >
> >> > Given this, I'm now slightly surprised that you're willing to allow =
{lo}
> >> > to ever give a Skolem function rather than a constant!
> >>
> >> If the selbri that "lo" transforms into a sumti contains an unbound
> >> variable, then I don't see how "lo" can create out of it anything
> >> other than a function.
> >
> > So am I taking "{lo} -> {zo'e noi}" too literally?
>=20
> Hmm... Maybe you are right, and it never need be a function, or at
> least not always. It needs more thought.

This trick of generalising out of a quantifier only works with kinds, of
course; so requiring that it always be a constant would make it even
rarer that {lo} gets interpreted as some mundanes.

Martin

--ofZMSlrAVk9bLeVm
Content-Type: application/pgp-signature

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

iEYEARECAAYFAk6aLC8ACgkQULC7OLX7LNaxLQCggCJrGOIqA4dOR5fItLMKyxWD
YTUAoL3v7MZ49EmTEO9syS7Gz5X1T+Qh
=yfeg
-----END PGP SIGNATURE-----

--ofZMSlrAVk9bLeVm--