Received: from mail-pz0-f61.google.com ([209.85.210.61]:58694) by stodi.digitalkingdom.org with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) (envelope-from ) id 1R78KB-0006rl-Fl; Fri, 23 Sep 2011 09:10:11 -0700 Received: by pzk32 with SMTP id 32sf3139489pzk.16 for ; Fri, 23 Sep 2011 09:09:57 -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=Re31G8kQzIyOoRc2py4MVFf3MVXpzWt2wUXHiYYR5RE=; b=CptVxoAwztMwayLJJ5C4gIhXsEiyEJ4O/NmVCsGOBftYA5X8KsBtr95U8acy10xNwz oKQK5T0cK8rz5YBlUp89RsR4fu2V1H2mAlCGXQ32AFnPgTzfrTfUlgl3RmCd+Y9uJ21m ASzmguuyQq7s6za01S75yv7b7UDptOrzqUWGY= Received: by 10.68.38.195 with SMTP id i3mr172720pbk.2.1316794196061; Fri, 23 Sep 2011 09:09:56 -0700 (PDT) X-BeenThere: lojban@googlegroups.com Received: by 10.68.120.168 with SMTP id ld8ls11678011pbb.7.gmail; Fri, 23 Sep 2011 09:09:55 -0700 (PDT) Received: by 10.68.38.134 with SMTP id g6mr7687400pbk.6.1316794195184; Fri, 23 Sep 2011 09:09:55 -0700 (PDT) Received: by 10.68.38.134 with SMTP id g6mr7687399pbk.6.1316794195171; Fri, 23 Sep 2011 09:09:55 -0700 (PDT) Received: from sdf.lonestar.org (mx.sdf.org. [192.94.73.19]) by gmr-mx.google.com with ESMTPS id kr11si1403554pbb.1.2011.09.23.09.09.55 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 23 Sep 2011 09:09:55 -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 p8NG9rZV011464 for ; Fri, 23 Sep 2011 16:09:54 GMT Received: from martin by gonzales.homelinux.org with local (Exim 4.75) (envelope-from ) id 1R78K1-0004gD-Qi for lojban@googlegroups.com; Fri, 23 Sep 2011 12:09:53 -0400 Date: Fri, 23 Sep 2011 12:09:53 -0400 From: Martin Bays To: lojban@googlegroups.com Subject: Re: [lojban] {zo'e} as close-scope existentially quantified plural variable Message-ID: <20110923160953.GB18894@gonzales> References: <20110919231314.GI4310@gonzales> <20110920034640.GK4310@gonzales> <20110921011503.GS4310@gonzales> <20110922035512.GA23348@gonzales> <20110923004537.GC24443@gonzales> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JYK4vJDZwFMowpUq" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://mbays.freeshell.org/pubkey.asc X-PGP-KeyId: B5FB2CD6 X-cunselcu'a-valsi: cange 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: , X-Spam-Score: -0.0 (/) X-Spam_score: -0.0 X-Spam_score_int: 0 X-Spam_bar: / --JYK4vJDZwFMowpUq Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Friday, 2011-09-23 at 12:04 -0400 - John E. Clifford : > The problem with scope is usually in {zo'e} place. Not that it is > a quantified variable so much as that it is anaphora for something > that is hooked to the quantifier or it's surrogate (in this case in > conjunctive distribution or generalization). Or, as I'll continue to suggest until I see a reason to stop, that it's quantification over a domain which is hooked to the outer quantifier. =20 > I'm not sure what plural quantification is, but piro lo broda is just > lo broda (maybe with restriction on distribution -- i'm not sure). {pi ro} was a stupid mistake. Make it {ro pi za'u}, maybe. > Pi su'o lo broda is some subbunch. Yes, i.e. a plural existential quantifier. No? Though it should probably be {pi za'u} rather than {pi su'o}, really. And be short for {su'o pi za'u}, maybe. > The singular/ plural debate seems pointless, given the parallelism of > L-sets and plural reference . I am under the impression that by now the three of us are in agreement on at least the basics of plural reference in lojban. You confuse me by seeming to allow bunches consisting of individuals =66rom various worlds. I don't see how to handle that, and my instinct is to like it even less than generics-via-kinds. Martin > On Sep 22, 2011, at 20:45, Martin Bays wrote: >=20 > > * Thursday, 2011-09-22 at 19:39 -0300 - Jorge Llamb=EDas : > >=20 > >> On Thu, Sep 22, 2011 at 12:55 AM, Martin Bays wrote: > >>> * Wednesday, 2011-09-21 at 19:08 -0300 - Jorge Llamb=EDas : > >>>>>> ro klesi be lo gerku cu gerku > >>>=20 > >>>> The problem with saying it is false is that if "lo blabi gerku > >>>> cu klesi lo gerku" is true, and "lo blabi gerku cu gerku" is also > >>>> true, it's hard to say why at least "su'o klesi be lo gerku cu gerku" > >>>> would not be true. > >>>=20 > >>> But we already have the same kind of weirdness with plurals: > >>> lo gerku remei cu remei .i je lo gerku remei cu gerku .i je ku'i ro > >>> remei na ku gerku remei > >>=20 > >> .i su'o boi re mei ja'a gerku re mei .i mu'a lo gunma be lo re gerku > >> be'o noi re mei cu gerku re mei > >=20 > > Well OK, maybe we aren't agreeing on how {mei} works. > >=20 > > Nor gunmas. Allowing gerku gunmas to gerku would cause the same kind of > > quantification problems we saw with kinds... I suppose you want to skirt > > these problems by further restricting common domains? > >=20 > >>> Generally: you can't quantify over plurals (assuming we agree to the > >>> extent I'm under the impression we do on how plurals work); not being > >>> able to quantify kinds is a similar kind of restriction. > >>=20 > >> I do think we agree that Lojban quantifiers are singular (you could > >> quantify over plurals with plural quantifiers, which Lojban apparently > >> doesn't have > >=20 > > Well actually... aren't {pi ro} and {pi su'o} plural quantifiers? > >=20 > >> ). > >> And I agree that a plural constant cannot be a witness for the > >> singular existential quantifier. > >=20 > > Great. I think we actually do see eye to eye as regards plurals. One in > > the nose for those who claim these discussions never come to anything, > > eh? Or at least it will be once it gets written up (which I still think > > slightly premature)... > >=20 > >> So you would be saying that "lo pa klesi be lo gerku" is to be treated > >> as plural? > >=20 > > Assuming that gives a kind: not *as* a plural, but *like* a plural as > > regards singular quantification. > >=20 > > In particular, I'd guess that using a singular quantifier on a kind > > should resolve as quantification over instances of the kind. > > (And if it's a kind of kinds... over the union of the instances of the > > kinds, I guess) > >=20 > >>>> It could. So in your system "lo du'u ko'a ckaji lo ka broda na nibli > >>>> lo du'u ko'a broda" is true, right? > >>>=20 > >>> Depends what you mean... for any predicate broda, I would want that to > >>> be false. But {se tuple re da} is not just a predicate in the above u= ses > >>> - it introduces an existential, and (part of) the question is what sc= ope > >>> that existential has. Stuffing it inside a {lo ka} prevents it from > >>> scoping over the {lo remna}. > >>=20 > >> For me "lo remna" is a constant, so there is no scoping over it. What = about: > >>=20 > >> lo remna zo'u re da zo'u da tuple ry > >> "As for humans, there are two things that be-leg them." > >>=20 > >> Would that be enough to keep your "lo remna" outside the scope of "re"? > >=20 > > Not as I'm currently thinking I'd like to understand anaphora, no. That > > would be almost or exactly equivalent to {re da tuple lo remna} - the > > only possible difference being that since {lo remna} is in the scope of > > the {re da} in the latter, it possibly should get interpreted twice with > > possibly different results. But that isn't the issue we were talking > > about. > >=20 > > (Although JC and I are talking about it elsewhere in another strand of > > this tangled thread, re the skina example) > >=20 > > Generally: I'm still basically hoping for the Nirvana Conjecture > > I mentioned earlier, even once (at least simple cases of) anaphora are > > included. In those terms, we're talking here about the meaning of > > predications some of whose arguments are zo'e-expressions - which is > > a second stage of processing after all anaphora etc are resolved. > > I think. > >=20 > >>> But wait, I was missing something obvious. > >>>=20 > >>> You can still use {lo}: > >>> {ro da poi na'e xanto se danlu zo'u lo xanto cu bramau lo tumla danlu= be da}. > >>=20 > >> Sure, that works too. Most predicates don't come with a built-in > >> subkind place though: > >>=20 > >> lo smoka cu cmamau ro drata taxfu > >>=20 > >> But you could appeal to fi'o klesi: > >>=20 > >> ro da poi na'e smoka klesi lo taxfu zo'u lo smoka cu cmamau lo taxfu > >> be fi'o klesi da > >=20 > > Yes, could be. > >=20 > > Alternatively, how about having {pi ro} quantify over subkinds, such > > that {lo smoka cu cmamau pi ro lo taxfu poi na'e smoka klesi} works? > >=20 > >> Would you agree that "lo se danlu cu klesi lo danlu"? > >=20 > > I don't know... it might be nice, for purposes like the above, to have > > {klesi} hold *only* of kinds - and I think selda'u should be mundanes. > >=20 > > Martin >=20 > --=20 > You received this message because you are subscribed to the Google Groups= "lojban" group. > To post to this group, send email to lojban@googlegroups.com. > To unsubscribe from this group, send email to lojban+unsubscribe@googlegr= oups.com. > For more options, visit this group at http://groups.google.com/group/lojb= an?hl=3Den. >=20 --JYK4vJDZwFMowpUq Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iEYEARECAAYFAk58r1EACgkQULC7OLX7LNYDEwCeKqzVL6ivbpnbQuzByPmX0r4p A8kAnjnVZwik2uH3bnf5yU5O8NS4FhxR =LLkI -----END PGP SIGNATURE----- --JYK4vJDZwFMowpUq--