From lojban+bncCOTEtqyUDhCu86DzBBoEfqR83Q@googlegroups.com Wed Sep 07 20:42:49 2011 Received: from mail-pz0-f56.google.com ([209.85.210.56]) by chain.digitalkingdom.org with esmtp (Exim 4.72) (envelope-from ) id 1R1VVm-0002Er-D8; Wed, 07 Sep 2011 20:42:49 -0700 Received: by pzk33 with SMTP id 33sf644911pzk.1 for ; Wed, 07 Sep 2011 20:42:40 -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=ntsIgFDvq8pKV2D7k7FWpxFSokTQFZXgVAQ0SC2I1bo=; b=T98TJbwLeGME6FGssfBM2pslnfPS5EBQl7+M8ufRTFkxL8UfmiVGNN/k4QYykcoIKM 5BS2hTGC7M1+81ngPDyKBHYT2clqlGhi6BA9ZgTFRRnqQQzvNfah2kVNDmbMGZNi+vdk DnpVQpdPvIfPjBZ40g0/ePfya/XLk2IXwIzMY= Received: by 10.68.5.9 with SMTP id o9mr53806pbo.38.1315453358620; Wed, 07 Sep 2011 20:42:38 -0700 (PDT) X-BeenThere: lojban@googlegroups.com Received: by 10.68.34.164 with SMTP id a4ls9383029pbj.1.gmail; Wed, 07 Sep 2011 20:42:37 -0700 (PDT) Received: by 10.68.22.198 with SMTP id g6mr131472pbf.29.1315453357185; Wed, 07 Sep 2011 20:42:37 -0700 (PDT) Received: by 10.68.22.198 with SMTP id g6mr131471pbf.29.1315453357164; Wed, 07 Sep 2011 20:42:37 -0700 (PDT) Received: from sdf.lonestar.org (mx.sdf.org. [192.94.73.19]) by gmr-mx.google.com with ESMTPS id ll18si4781685pbb.0.2011.09.07.20.42.37 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Sep 2011 20:42:37 -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.4/8.14.3) with ESMTP id p883gauv002590 for ; Thu, 8 Sep 2011 03:42:36 GMT Received: from martin by gonzales.homelinux.org with local (Exim 4.75) (envelope-from ) id 1R1VVc-0002EN-9D for lojban@googlegroups.com; Wed, 07 Sep 2011 23:42:36 -0400 Date: Wed, 7 Sep 2011 23:42:36 -0400 From: Martin Bays To: lojban@googlegroups.com Subject: Re: [lojban] {zo'e} as close-scope existentially quantified plural variable Message-ID: <20110908034236.GM30833@gonzales> References: <20110907030141.GA30833@gonzales> <20110908003133.GJ30833@gonzales> <20110908020307.GK30833@gonzales> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xQmOcGOVkeO43v2v" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://mbays.freeshell.org/pubkey.asc X-PGP-KeyId: B5FB2CD6 X-cunselcu'a-valsi: kecti 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: X-Google-Group-Id: 1004133512417 List-Post: , List-Help: , List-Archive: Sender: lojban@googlegroups.com List-Subscribe: , List-Unsubscribe: , --xQmOcGOVkeO43v2v Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Wednesday, 2011-09-07 at 23:58 -0300 - Jorge Llamb=EDas : > On Wed, Sep 7, 2011 at 11:03 PM, Martin Bays wrote: > > * Wednesday, 2011-09-07 at 21:47 -0300 - Jorge Llamb=EDas : > >> > >> I was still thinking in terms of possible answers to "xu do klama lo > >> zarci". In such a context, I would take the referents for "zo'e" in > >> "ro ma'a klama [zo'e]" to be the same as for "lo zarci". > > > > Ah. So in other contexts, {ro ma'a klama} could be true without the > > destinations being the same for different referents of {ma'a}? But only > > because you'd have the zo'e mean the generic "destinations"? >=20 > Right. >=20 > > If you introduce such generics, it seems that it becomes impossible to > > unambigously specify order of quantifiers. This, surely, is a Very Bad > > Thing. >=20 > Scope of quantifiers is always unambiguous. What I think is impossible > is to fix one domain of discourse for all discourse independent of its > context. >=20 > > I mean: you seem to be suggesting that for any broda(x,y) and any domain > > of discourse M, there should be another plausible domain of discourse *M > > extending M and an element *y \in *M such that > > \forall x\in M. (\exists y\in M. broda(x,y) =3D> broda(x,*y) ). >=20 > I'm not sure I follow. If *y is meant to be a generic term for some > things already existing in M Yes > , then I would consider the extended domain *M implausible rather than > plausible. I would think that in most plausible domains of discourse > the generic doesn't coexist with its manifestations. Making them > coexist takes some special effort. Sorry, yes, you did say that in the other thread. But it doesn't really affect the logic here. > > But then if I do say {su'o de ro da zo'u da broda de}, it could be that > > I'm working in M and really mean to make the strong assertion > > M satisfies \exists y. \forall x. broda(x,y) , > > or I could be working in *M and hence be claiming only > > M satisfies \forall x. \exists y. broda(x,y) . >=20 > Yes, if I say "there's some fruit that everybody ate" I could be > saying (and probably would be saying) that everybody ate apples, for > example. Is that what you mean? Yes, precisely. The ambiguity would be widerspread than in English, of course. You can't say "someone loves everyone" and mean that the generic lover does, but you could with {da prami ro de}. And if this generic lover is invoked by innocuous phrases like {ro se mamta cu se prami}, it wouldn't be a particularly exotic reading. > > The only way to tell which I meant would be informal rules about saying > > things in the least confusing way. >=20 > Yes, if you thought there was some risk of confusion as to what the > domain of discourse was, you would need to be more precise: "there's > some kind of fruit that everybody ate" vs "there's some individual > fruit that everybody ate". But that's unavoidable, since the domain of > discourse is not uniquely fixed for any and all contexts. >=20 > > So no, I don't think such tricks should be resorted to unless absolutely > > necessary - and if they do prove necessary, I'd think it a problem with > > the language. >=20 > You call them tricks, but I think it's an ordinary part of language. You may be right that it's impractical to grammatically distinguish between generics and mundanes (and perhaps also that there isn't a coherent distinction between the two), though I'm not really convinced yet. But even if so, introducing with zo'e these generics which demonstratedly *aren't* necessary, because they don't really exist in natural languages, seems unhealthy. > >> > It sounds like you might be giving it longest scope rather than > >> > shortest, which gets around that kind of issue... though it still ha= s to > >> > scope inside the da in {ro da zo'u broda zo'e noi brode da}. > >> > >> I don't give it any kind of scope, since I don't think constants have > >> scope. But if you do need to force constants to be quantified, then > >> yes, I would have to favour longest over shortest. > > > > What's the alternative to scope? > > > > I thought we agreed earlier today that zo'e isn't literally a constant > > in general, e.g. it has to scope inside {da} in the above example. >=20 > But functions don't have scope either, it is quantifiers that have > scope. If a function happens to take a bound variable as an argument, > then its value will be determined within the scope of the quantifier > that binds that variable, yes. I think this is just different language for the same thing - i.e. you're Skolemising away the existential quantifiers (http://en.wikipedia.org/wiki/Skolem_normal_form). --xQmOcGOVkeO43v2v Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iEYEARECAAYFAk5oOawACgkQULC7OLX7LNZ+JwCcDrpDWLemPgvmeIZaxs+p2pj7 6jAAnjkZHzFsDzuDCZyvfGf4EPzwU0KB =7hmy -----END PGP SIGNATURE----- --xQmOcGOVkeO43v2v--