Received: from mail-lb0-f186.google.com ([209.85.217.186]:54501) by stodi.digitalkingdom.org with esmtps (TLSv1:RC4-SHA:128) (Exim 4.80.1) (envelope-from ) id 1XdPgW-00046B-1k for lojban-list-archive@lojban.org; Sun, 12 Oct 2014 13:24:16 -0700 Received: by mail-lb0-f186.google.com with SMTP id z12sf603634lbi.13 for ; Sun, 12 Oct 2014 13:23:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20120806; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :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:content-type; bh=JbsGCxqh0Smn9OS76ZZWEOS0bvrE6t2vsPUWQDs8jGw=; b=eA6wYuA3dQ9JUMJBCbU1IdgR+xRwRgHaL0Ts+jFsy8rntbcOX7kFNimB10HSr1glkm ZFTEgDxFb6FkoAa+tpL1b85tGvEdDhTzeZBlBFPz8tPJdOMeNDPe+2/B+TMMZO2UK5Hy v2kdEuKouFLTtgveqBfBpyKyTe/iYCvWEe+ui0yfpAcGu2nMKHRL3acMZs7utPsXU93s vFSSozGYmlMJyYBf1B5uK8+jSHbKK8tK2UR2U6rnW1cALe15pCpcxDBqkdKr0xYSRuea RCy7WEYUbv0i71xmVkkAPaBnTdIuwvGs8E+w+p9s8JYdPu7Bx6aS/UZQidXzG/3a9yip mJsQ== X-Received: by 10.180.88.102 with SMTP id bf6mr3196wib.15.1413145439922; Sun, 12 Oct 2014 13:23:59 -0700 (PDT) X-BeenThere: lojban@googlegroups.com Received: by 10.180.171.70 with SMTP id as6ls65117wic.12.gmail; Sun, 12 Oct 2014 13:23:59 -0700 (PDT) X-Received: by 10.194.20.229 with SMTP id q5mr3314758wje.2.1413145439359; Sun, 12 Oct 2014 13:23:59 -0700 (PDT) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [2a00:1450:4010:c04::232]) by gmr-mx.google.com with ESMTPS id us10si478041lbc.1.2014.10.12.13.23.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 12 Oct 2014 13:23:59 -0700 (PDT) Received-SPF: pass (google.com: domain of jjllambias@gmail.com designates 2a00:1450:4010:c04::232 as permitted sender) client-ip=2a00:1450:4010:c04::232; Received: by mail-lb0-f178.google.com with SMTP id w7so5609478lbi.9 for ; Sun, 12 Oct 2014 13:23:59 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.142.104 with SMTP id rv8mr19076092lbb.59.1413145439217; Sun, 12 Oct 2014 13:23:59 -0700 (PDT) Received: by 10.114.61.107 with HTTP; Sun, 12 Oct 2014 13:23:59 -0700 (PDT) In-Reply-To: <20141012173533.GG23876@gonzales> References: <20141009233031.GC1592@gonzales> <20141010234033.GG22868@gonzales> <20141011021201.GH22868@gonzales> <20141011143749.GD23876@gonzales> <20141012012427.GF23876@gonzales> <20141012173533.GG23876@gonzales> Date: Sun, 12 Oct 2014 17:23:59 -0300 Message-ID: Subject: Re: [lojban] Re: tersmu 0.2 From: =?UTF-8?Q?Jorge_Llamb=C3=ADas?= To: lojban@googlegroups.com X-Original-Sender: jjllambias@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jjllambias@gmail.com designates 2a00:1450:4010:c04::232 as permitted sender) smtp.mail=jjllambias@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=gmail.com 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: , Content-Type: multipart/alternative; boundary=001a11c3783eebb04505053f8fb8 X-Spam-Score: -1.9 (-) X-Spam_score: -1.9 X-Spam_score_int: -18 X-Spam_bar: - --001a11c3783eebb04505053f8fb8 Content-Type: text/plain; charset=UTF-8 On Sun, Oct 12, 2014 at 2:35 PM, Martin Bays wrote: > > I was thinking of the {co'e}. Must {tu'a ko'a} refer to the same > abstraction every time it appears in a sentence? e.g. in {tu'a ko'a > rinka lo nu mi djica tu'a ko'a}? If not, we can't really model it as > a function. > It need not be always the same function, but I would still call it a function in the same sense I would call "co'e" a predicate and "zo'e" a constant. Here's why transparency seems simplest to me: once we ignore exceptions > like {tu'a}, and assuming definiteness of {lo}, and considering only > simple sumti, what we've done by defining a binary relation and then > hitting it with {lo} is actually to define a unary function. So we > *could* decide at this point that we're back with the simplest semantics > where each qualifier is interpreted as a unary function; we've just > given a slightly baroque explanation for what that unary function is. > Since in most cases there's a clear choice for the function which > doesn't need {lo} to explain it, this seems very natural to me. > > If we think that way, hiding the step with {lo}, transparency is the > only option - because there's no longer a subbridi in sight. > All right, taking LAhE as primitives does make things simpler in one sense. I just think it's simpler in a more fundamental sense to have fewer primitives, and especially fewer primitive types. > > "fa'u" and "ju'e" are exceptions in an opposite sense than "tu'a". > Whereas > > "tu'a" constrains the bridi-operators that it takes as arguments to act > on > > a subordinate predicate, "fa'u" and "ju'e" are themselves bridi operators > > that act on a superordinate bridi. > > I see that for fa'u. Why for ju'e? What does it do? > I don't really know, but what I guess from the definition: <> is: ko'a ju'e ko'e broda <-> ko'a broda .i ko'e broda i.e. a watered down version of ".e" > Also, to give an argument of the kind that And would disapprove of, I > think > > that as a general rule sumti-6 should not be bridi operators, and since > > LAhE is in sumti-6, it should generate a logical term, not a pseudo-term. > > I'm probably more swayed by this kind of argument than I should be, but > it would indeed be nice for unbound variables to be the only > exception... > > (well actually {ma} is something of an exception too, but in a quite > different way) > And "ko" and "zi'o" as well. > This argument doesn't apply to JOI, which shows up higher up in the > grammar. > > Interesting point... but I still feel JOI should be opaque if LAhE is. > This has knock-on effects elsewhere, by the way. Currently I have e.g. > {pu je ca bi'o ba nolraitru} <-> > {pu bi'o ba nolraitru .i je ca bi'o ba nolraitru} > which fits with transparency for non-logical connectives on sumti. > I don't really know if this is right. Same story for operators (but not > for tanru connectives). > One interesting thing about tag connectives is that they don't allow bo/ke grouping, so that would mean that some expanded forms cannot be condensed. (That could probably be fixed in PEG.) But in the case of tags, even if we take them as nonprimitive and expand them, we could still go either way, since there's no rule that says that "fi'o se purci je fi'o se cabna" has to be "fi'o se purci je se cabna". > > > lo djacu cu dunja lo ka kelvo li no > Oops, I meant "jacke'o" (or "celso"), not kelvo. I think it's impossible to reach kelvo li no, isn't it? > lo cipni cu se farvi lo dinsauru > > Should a kind reading be available even if we're in the process of > talking about instances? Even if they're used elsewhere in the sentence? > e.g. is this legitimate, where kinds are intended only within the du'u: > > lo djacu cu ba zi spojygau lo botpi noi dy nenri ku ri'a lo du'u ge lo > djacu cu dunja lo ka kelvo li no gi lo sligu djacu cu denmi mleca lo > litki djacu > > ? I don't have a problem with it. > If not, maybe \iota is the right thing after all. > > Or would you allow this, but only because of a domain shift within the > du'u (so it wouldn't be allowed if both {lo djacu} were at main bridi > level)? No, I wouldn't even have a problem with: lo djacu cu dunja lo ka celso li no kei gi'e ba zi bo spojygau lo botpi noi dy nenri mu'o mi'e xorxes -- You received this message because you are subscribed to the Google Groups "lojban" group. To unsubscribe from this group and stop receiving emails from it, send an email to lojban+unsubscribe@googlegroups.com. To post to this group, send email to lojban@googlegroups.com. Visit this group at http://groups.google.com/group/lojban. For more options, visit https://groups.google.com/d/optout. --001a11c3783eebb04505053f8fb8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Oct 12, 2014 at 2:35 PM, Martin Bays <mbays@sdf.org>= wrote:

I was thinking of the {co'e}. Must {tu'a ko'a} refer to = the same
abstraction every time it appears in a sentence? e.g. in {tu'a ko'a=
rinka lo nu mi djica tu'a ko'a}? If not, we can't really model = it as
a function.

It need not be always the s= ame function, but I would still call it a function in the same sense I woul= d call "co'e" a predicate and "zo'e" a constant= .=C2=A0

Here's why transparency se= ems simplest to me: once we ignore exceptions
like {tu'a}, and assuming definiteness of {lo}, and considering only simple sumti, what we've done by defining a binary relation and then hitting it with {lo} is actually to define a unary function. So we
*could* decide at this point that we're back with the simplest semantic= s
where each qualifier is interpreted as a unary function; we've just
given a slightly baroque explanation for what that unary function is.
Since in most cases there's a clear choice for the function which
doesn't need {lo} to explain it, this seems very natural to me.

If we think that way, hiding the step with {lo}, transparency is the
only option - because there's no longer a subbridi in sight.

All right, taking LAhE as primitives does make th= ings simpler in one sense. I just think it's simpler in a more fundamen= tal sense to have fewer primitives, and especially fewer primitive types.
=C2=A0
> "fa'u&= quot; and "ju'e" are exceptions in an opposite sense than &qu= ot;tu'a". Whereas
> "tu'a" constrains the bridi-operators that it takes as a= rguments to act on
> a subordinate predicate, "fa'u" and "ju'e"= are themselves bridi operators
> that act on a superordinate bridi.

I see that for fa'u. Why for ju'e? What does it do?

I don't really know, but what I guess from = the definition: <<vague non-logical = connective: analogous to plain ".i".>> is:

ko'a ju'e ko'e broda <-> ko'a broda .i = ko'e broda=C2=A0

=
i.e. a watered down version of = =C2=A0".e"

> Also, to give an argument of the= kind that And would disapprove of, I think
> that as a general rule sumti-6 should not be bridi operators, and sinc= e
> LAhE is in sumti-6, it should generate a logical term, not a pseudo-te= rm.

I'm probably more swayed by this kind of argument than I should = be, but
it would indeed be nice for unbound variables to be the only
exception...

(well actually {ma} is something of an exception too, but in a quite
different way)

And "ko" and &= quot;zi'o" as well.=C2=A0

> This argument doesn't apply to JOI, which shows up higher up in th= e grammar.

Interesting point... but I still feel JOI should be opaque if LAhE i= s.=C2=A0

This has knock-on effects elsewhere, by the way. Currently I have e.g.
{pu je ca bi'o ba nolraitru} <->
=C2=A0 =C2=A0 {pu bi'o ba nolraitru .i je ca bi'o ba nolraitru}
which fits with transparency for non-logical connectives on sumti.
I don't really know if this is right. Same story for operators (but not=
for tanru connectives).

One interesting= thing about tag connectives is that they don't allow bo/ke grouping, s= o that would mean that some expanded forms cannot be condensed. (That could= probably be fixed in PEG.)

But in the case of tag= s, even if we take them as nonprimitive and expand them, we could still go = either way, since there's no rule that says that "fi'o se purc= i je fi'o se cabna" has to be "fi'o se purci je se cabna&= quot;.

>
>=C2=A0 lo djacu cu dunja lo ka kelvo li no

Oops, I meant "jacke'o&quo= t; (or "celso"), not kelvo. I think it's impossible to reach = kelvo li no, isn't it?

>=C2=A0 lo cipni cu se farvi lo dinsauru

Should a kind reading be available even if we're in the process = of
talking about instances? Even if they're used elsewhere in the sentence= ?
e.g. is this legitimate, where kinds are intended only within the du'u:=

lo djacu cu ba zi spojygau lo botpi noi dy nenri ku ri'a lo du'u ge= lo
djacu cu dunja lo ka kelvo li no gi lo sligu djacu cu denmi mleca lo
litki djacu

?

I don't have a problem with it.
=
=C2=A0
If not, maybe \iota is the right thing a= fter all.

Or would you allow this, but only because of a domain shift within the
du'u (so it wouldn't be allowed if both {lo djacu} were at main bri= di
level)?

No, I wouldn't even have a prob= lem with:

=C2=A0 =C2=A0lo djacu cu dunja lo ka cel= so li no kei gi'e ba zi bo spojygau lo botpi noi dy nenri
mu'o mi'e xorxes

--
You received this message because you are subscribed to the Google Groups &= quot;lojban" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to lojban+unsub= scribe@googlegroups.com.
To post to this group, send email to lojban@googlegroups.com.
Visit this group at http:= //groups.google.com/group/lojban.
For more options, visit http= s://groups.google.com/d/optout.
--001a11c3783eebb04505053f8fb8--