Received: from mail-vc0-f192.google.com ([209.85.220.192]:50009) by stodi.digitalkingdom.org with esmtps (TLSv1:RC4-SHA:128) (Exim 4.80.1) (envelope-from ) id 1XfdYp-0001R5-FK for lojban-list-archive@lojban.org; Sat, 18 Oct 2014 16:37:29 -0700 Received: by mail-vc0-f192.google.com with SMTP id hq11sf433619vcb.9 for ; Sat, 18 Oct 2014 16:37:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20120806; h=date:from:to:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :sender:list-subscribe:list-unsubscribe; bh=wbiZjp+ZLgQl0XlBEXlJax+7iuB+o8eFzO5zSEB7qSM=; b=gPkbGMEcAuJ1HKjG1s/eqLoI6p/ONwkmIOJaYMqDJt11Ec6O2RFlLlA3+kO94eFjmx qYCcOHIxMCG1tTYWtSgEBtLYgM4s7yASUaX6wGwmoOj8kknkRxGDME5L3hVgkO/xpI73 3AWecQWJC14NuNqfA3i/MFfaZFgx1fbJCz5PpGKo6GvCkLN+UMasHSub/uxaYV7vRtF1 WEnI98h/P3h21W+VjGIENbs+Mul4oYor7B5dbktfyS74YwPUH5Mw1Q+3a5+YpsY1BkyH P5Yvl9x43tRqQ1Z3aecmQKu8QLXoKdDNJS29p27J7krcvn5i8/aXrpxrJjzffSlRi1ej Q6PA== X-Received: by 10.140.84.21 with SMTP id k21mr4676qgd.6.1413675436784; Sat, 18 Oct 2014 16:37:16 -0700 (PDT) X-BeenThere: lojban@googlegroups.com Received: by 10.140.81.199 with SMTP id f65ls1713232qgd.5.gmail; Sat, 18 Oct 2014 16:37:16 -0700 (PDT) X-Received: by 10.236.30.69 with SMTP id j45mr11810507yha.23.1413675436519; Sat, 18 Oct 2014 16:37:16 -0700 (PDT) Received: from sdf.lonestar.org (mx.sdf.org. [192.94.73.24]) by gmr-mx.google.com with ESMTPS id yr4si540833pab.1.2014.10.18.16.37.16 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 18 Oct 2014 16:37:16 -0700 (PDT) Received-SPF: none (google.com: mbays@sdf.org does not designate permitted sender hosts) client-ip=192.94.73.24; Received: from thegonz.net (d24-141-9-29.home.cgocable.net [24.141.9.29]) (authenticated (0 bits)) by sdf.lonestar.org (8.14.8/8.14.5) with ESMTP id s9INacHo003322 (using TLSv1/SSLv3 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits) verified NO) for ; Sat, 18 Oct 2014 23:36:40 GMT Received: from martin by thegonz.net with local (Exim 4.80.1) (envelope-from ) id 1XfdYG-0006NG-W1 for lojban@googlegroups.com; Sat, 18 Oct 2014 19:36:49 -0400 Date: Sat, 18 Oct 2014 19:36:48 -0400 From: Martin Bays To: lojban@googlegroups.com Subject: Re: [lojban] Re: tersmu 0.2 Message-ID: <20141018233648.GA29040@gonzales> References: <20141012173533.GG23876@gonzales> <20141014010742.GF19061@gonzales> <20141015005542.GC3713@gonzales> <20141018004531.GE20049@gonzales> <20141018180946.GF20049@gonzales> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HlL+5n6rz5pIUxbD" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://mbays.freeshell.org/pubkey.asc X-PGP-KeyId: B5FB2CD6 X-cunselcu'a-valsi: purmo 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: X-Google-Group-Id: 1004133512417 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -1.9 (-) X-Spam_score: -1.9 X-Spam_score_int: -18 X-Spam_bar: - --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Saturday, 2014-10-18 at 18:21 -0300 - Jorge Llamb=EDas : > On Sat, Oct 18, 2014 at 3:09 PM, Martin Bays wrote: > > (i) a bridi operator operates on the bridi immediately under > > construction, i.e. the lowest in the tree; > > (ii) a logical connective acts as a bridi operator, connecting the > > two formulae obtained by substituting each connectand in turn > > for the connected element. >=20 > Right, so for each context in which "ko'a .e ko'e" may appear, we need to > know whether the context introduces a bridi of its own. Yes. Similarly for contexts in which other logically connected constructs may appear. So we're not so much discussing how to handle complex sumti in various contexts, as discussing which constructs introduce bridi. > As I see it, having to know that is tantamount to having a rule for > each context. Well, a rule for each construct. We need to know how to interpret each construct in the grammar (obviously!), part of which is determining whether it introduces a bridi. The handling of logical connectives then follows by (i) and (ii) above, and similarly for other bridi operators. > I don't really know how mex work, so I'm only asking questions at this > point. I would expect that "na'u sinso mo'e ko'a .e mo'e ko'e" within mex > would work in the same way as "lo sinso be ko'a .e ko'e" outside of mex. I > take "na'u" to be the mex equivalent of "lo", since it converts a predica= te > into a function. I don't know exactly why the language needs a parallel m= ex > sub-language, but if it's going to have one it should at least work as > closely as possible to how the main language works. If "na'u sinso" does > not introduce a bridi of its own, why would "lo sinso be", which has the > same meaning, do? Right, so we come back to the question of whether the underlying logic has functions. If we declare that it's purely relational, then all the constructs which have the form of functions - operators, qualifiers, non-logical connectives, and I guess also {jo'i} (this list should be exhaustive) - must actually translate to relations, so it's natural that they should introduce sub-bridi. It's certainly true that purely relational logics are easier to reason about, and that there's no loss in expressivity when eliminating functions in favour of relations. But it still feels very counter-intuitive to me that these things which look like functions shouldn't just be functions. Maybe it's worth considering utility again briefly, in this rather pure case of operators. Mex may be an obscure part of the language, but I can think of examples where having operators be functions gives useful results; e.g. li no pi'i mo'e ro namcu du li no li xy mleca li re .e se ni'i bo ci (I'm also assuming here that {li} doesn't introduce a bridi.) The first one is also true with the relational semantics, but I'm not sure it expresses the same thing (I'd translate it as "the thing which is 0 times anything is 0", so the fact that such a thing exists becomes a presupposition rather than a statement). The only examples I can think of where you even get something that makes sense are ones of this kind of form. (Yes, I know, this is a part of the language which hasn't seen much use anyway, so arguments from utility can't have much force here... but the situation seems pretty similar with LAhE and JOI and so on.) > > So this handling of {mo'e ko'a .e ko'e} involves a "new rule"? >=20 > Yes, "mo'e" converts a (logical) sumti into a (logical) operand, i.e. it > doesn't really do anything meaningful since logically a sumti and an > operand are the same thing. All it does is take a term from the standard > form of the language and put it in a from that can be used within mex. We > do need to specify as an additional rule what happens when instead of > giving it a logical sumti we give it a pseudo-sumti, something that is > morphologically a sumti but logically something else. Since operands also > have their corresponding pseudo-operands, it might very well make sense to > say that "mo'e" also converts pseudo-sumti into their corresponding > pseudo-operand, i.e. that "mo'e ko'a .e ko'e" is "mo'e ko'a .e mo'e ko'e"' OK. We get the same results, though, if rather than explicitly specifying these rules for complex sumti, we just say that {mo'e} converts a *term* to an operand, and use the usual rules to get terms out of complex sumti for this to apply to. > Now "mo'e ro da" would be the way to do quantification within mex (though > there's no pseudo-operand corresponding to "ro da" in the way that "mo'e > ko'a .e mo'e ko'e" corresponds to "ko'a .e ko'e"). Right, so here thinking about it as I just described is also helpful - the resulting operand is just {mo'e da}, and the quantification happened when we parsed the {ro da}. > But then the argument for "mo'e" would seem to apply just as well to "li" > for the reverse direction, in which case "li pa .a re" would have to be "= li > pa .a li re". This unfortunately makes li-clauses break the sumti-6 being > pure terms rule. I don't think we should really worry about that rule. It would be neat if it worked out to be true, but there's plenty in the grammar that isn't and can't easily be made neat. > > > The operator "na ku zo'u" is only well defined when > > > applied to a single proposition. When applied to multiple proposition= s at > > > once, who knows how we want it to act. Maybe it should be distributiv= e. > > I guess it could! Yet another thing to be decided. Do you think it might > > be a bad idea to decide that it's equivalent to "na ku go broda gi > > brode"? >=20 > Why "go"? That would mean that one of the propositions is true and the > other false. What would be the generalization to "na ku zo'u tu'e broda .i > brode .i brodi tu'u"? Or did you mean "ga"? Sorry, I meant {ge}. (the vowels are in a contiguous line in dvorak... more of a problem for lojban than for most languages!) Is there a reason not to declare that {na ku zo'u tu'e broda .i brode} is equivalent to {na ku zo'u ge broda gi brode}? --HlL+5n6rz5pIUxbD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlRC+ZAACgkQULC7OLX7LNZX9ACgtDJ4HLcu9bjePxpLEHg7Kd3u /8cAnicph4Br+Cbcacd6KAEEgP0ngCV6 =lhYa -----END PGP SIGNATURE----- --HlL+5n6rz5pIUxbD--