Envelope-to: lojban-list-archive@lojban.org
Delivery-date: Thu, 07 Jan 2021 10:00:03 -0800
Sender: lojban@googlegroups.com
Received-SPF: pass (google.com: domain of jake@mail.jerrington.me designates 2001:41d0:2:863f:: as permitted sender) client-ip=2001:41d0:2:863f::;
Subject: Re: [lojban] Multiple-variable abstractions (WAS: Re: Reasoning by analogy)
To: lojban@googlegroups.com
References: <86o8iru85f.fsf@cmarib.ramside>
 <dd954228-c706-98f2-5709-eaed3cb94703@mail.jerrington.me>
 <86blep9yni.fsf@cmarib.ramside>
 <8ff75cde-1243-5188-489e-e11276a75a07@mail.jerrington.me>
 <86zh1s9mw5.fsf@cmarib.ramside>
 <103d554a-d7f5-918e-bb82-6e025e41131b@mail.jerrington.me>
 <86zh1lhoao.fsf_-_@cmarib.ramside>
From: Jacob Thomas Errington <jake@mail.jerrington.me>
Message-ID: <ab3d25ae-5b02-e7e0-a93a-4900fc5120ef@mail.jerrington.me>
MIME-Version: 1.0
In-Reply-To: <86zh1lhoao.fsf_-_@cmarib.ramside>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Date: Thu, 07 Jan 2021 17:59:57 GMT
Reply-To: lojban@googlegroups.com
Precedence: list
Mailing-list: list lojban@googlegroups.com; contact lojban+owners@googlegroups.com
X-Spam_score: -2.8
X-Spam_score_int: -27
X-Spam_bar: --

On 2021-01-06 14:13, scope845hlang343jbo@icebubble.org wrote:

>
> An example of a sentence exhibiting that ambiguity might be {ko'a ce'o
> ko'e ckaji loka porsi}.  Would that mean {ko'a ce'o ko'e porsi} or {ko'a
> porsi ko'e}?  It would be ambiguous.
>
> A way to resolve such ambiguity might be to treat {lo ka broda} as a
> solitary sumti (not a sequence) when the {ka} phrase doesn't contain
> {ce'u}, but as a sequence when it contains multiple {ce'u}.  Such a rule
> could become unwieldy when the property contains many arguments, i.e.
> {lo ka ce'u broda ce'u ce'u ce'u ...}.  So, I might propose the
> following rule:
>
>    (1) The property is interpreted as a sequence when two or more {ce'u}
>        are explicity expressed within it.
>
>    (2) Otherwise (when there are zero or one {ce'u}), it is interpreted
>        as a solitary sumti (as opposed to a sequence).
>
>    (3) Any unexpressed places following the second {ce'u}, if any, are
>        assumed to be {ce'u}.
Rule 3 only really works in simple abstractions; how does one deal with=20
situations like {lo ka ce'u broda lo pendo be ce'u}?
>
> This rule would introduce two questions: (A) How would one speak about a
> sequence with just one element?, and (B) How would one differentiate
> between properties with different numbers of arguments (arities)?
>
> If I say {ko'a ce'o zi'o ckaji lo ka ce'u porsi}, I'm speaking about a
> sequence containing one element, {ko'a}, but I'm not saying that {ko'a
> porsi}.  On the other hand, if I say {ko'a ckaji loka ce'u ce'u porsi},
> then it'd be true that {ko'a porsi}; it'd be the sequence {lo porsi ce'o
> lo se porsi be ri}.  The problem of specifying a sequence with just one
> element (A) is a challenged posed by Lojban's infix syntax, not by
> abstractors like {ka}.
I think a pretty reasonable interpretation of {ko'a ce'o zi'o} is a=20
1-tuple. Reminds me of Python's syntax (x,) for a 1-tuple.
>
> Issue (B), however, does not suggest any easy solutions.  Would {lo ka
> ce'u broda ce'u} be a property with two arguments, or a property with
> more than two arguments, such as {lo ka ce'u broda ce'u ce'u} or {lo ka
> ce'u broda ce'u ce'u ce'u}, with the trailing {ce'u} unexpressed?  It
> might be possible to quantify the number of arguments.
>
> A ternary property, {lo ka ce'u broda ce'u ce'u}, could be expressed as
> something like {lo ci ka broda} or {lo cimei ka broda}.  However, the
> tanru form would introduce the semantic ambiguity inherent in tanru.
> And the form with an inner quantifier might run afoul of Lojban's normal
> interpertation of quantifiers.
I'm not in favour of introducing an exception to the interpretation of=20
inner quantifiers to be able to specify the number of arguments,=20
especially when we're just cooking up new interpretations without=20
consulting any existing usage. Right now, there is no situation where=20
the number of arguments to a ka-abstraction is completely unclear. The=20
overt {ce'u} in a ka abstraction each represent separate sumti places=20
without any implicit tuple unpacking.
> This could be solved, however, by treating quantified abstractions as
> "magic", kind of like the way quantified variables of selma'o GOhA are
> treated magically in the terms of a prenex (preceeding {zo'u}).  I.e.,
> {ro bu'a zo'u broda} doesn't mean the same thing as {roda zo'u broda},
> because {ro bu'a zo'u} is magic.  So, if we consider {lo su'o ka} magic,
> could we use this mechanism to speak about multi-variable properties?

I don't agree that the existence of a wart in the language is a good=20
justification for the introduction of new warts. Not to mention that=20
following the shift in the last ten years to understand ka-abstractions=20
as reified selbri, there isn't really any reason to use {bu'a} except=20
maybe a slightly cleaner syntax. Ignoring syntax cleanliness, why say

 =C2=A0 .i ro bu'a zo'u da bu'a

when you could say

 =C2=A0 .i ro da poi selkai (zi'o) zo'u de da ckaji


I think that tuple unpacking / pattern matching is interesting, which is=20
why I already solved this exact problem by leveraging the experimental=20
cmavo {ce'ai}.

The way {ce'ai} works in general is that each sumti appearing in it is=20
understood as a binder. We concocted {ce'ai} back in ~2013 when=20
discussing how to reuse {ce'u} within a ka-abstraction. Here's a=20
contrived example:

 =C2=A0 without ce'ai: {.i mi ckaji lo ka ce'u goi ko'a batci ko'a}
 =C2=A0 with ce'ai: {.i mi ckaji lo ka ko'a ce'ai ko'a ko'a batci}

The idea is to have something specifically for introducing ce'u-like=20
bound variables, similar to the way {da} works in {zo'u}. My pattern=20
matching idea extends the original definition of {ce'ai} to allow more=20
complex sumti to appear in the {ce'ai}-clause, understanding them as=20
patterns. For example:

 =C2=A0 {ko'a ce'o ko'e ckaji lo ka X ce'o Y ce'ai X broda Y} interprets to=
=20
{ko'a broda ko'e}

(I'm writing capital letters to stand for the equivalent BY cmavo.)

It's also aligned with usual programming language theory because we use=20
the introduction form for tuples {ce'o} as a means of deconstructing the=20
tuple.

Personally, I see many pros, and very few cons. In fact, the only con I=20
can see is the use of an experimental cmavo. But using an experimental=20
cmavo for something that's admittedly a niche application seems right on=20
brand to me.

.i mi'e la tsani mu'o

P.S. are you a member of roljbogu'e discord server?


--=20
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 e=
mail to lojban+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/=
lojban/ab3d25ae-5b02-e7e0-a93a-4900fc5120ef%40mail.jerrington.me.