From lojbab@lojban.org Fri Oct 05 18:51:24 2001
Return-Path: <lojbab@lojban.org>
X-Sender: lojbab@lojban.org
X-Apparently-To: lojban@yahoogroups.com
Received: (EGP: mail-7_4_1); 6 Oct 2001 01:51:23 -0000
Received: (qmail 67580 invoked from network); 6 Oct 2001 01:51:08 -0000
Received: from unknown (10.1.10.142)
  by l7.egroups.com with QMQP; 6 Oct 2001 01:51:08 -0000
Received: from unknown (HELO stmpy-4.cais.net) (205.252.14.74)
  by mta3 with SMTP; 6 Oct 2001 01:51:07 -0000
Received: from bob.lojban.org (141.dynamic.cais.com [207.226.56.141])
  by stmpy-4.cais.net (8.11.1/8.11.1) with ESMTP id f961p4431214
  for <lojban@yahoogroups.com>; Fri, 5 Oct 2001 21:51:05 -0400 (EDT)
Message-Id: <4.3.2.7.2.20011005211929.00dbead0@pop.cais.com>
X-Sender: vir1036@pop.cais.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 05 Oct 2001 21:47:28 -0400
To: <lojban@yahoogroups.com>
Subject: RE: [lojban] On functions to various types of things.
In-Reply-To: <LPBBJKMNINKHACNDIIGMGEAMENAA.a.rosta@dtn.ntl.com>
References: <106.68ac9b5.28ece37d@aol.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
From: "Bob LeChevalier (lojbab)" <lojbab@lojban.org>

At 01:39 AM 10/6/01 +0100, And Rosta wrote:
>pc:
> > The discussion of {le mamta be ce'u} has gone on rather too long, so
> > a modest proposal (that just messes up a few years of text) seems in
> > order. Since no one seems to mind {ce'u} in the bridi following an
> > abstractor, when the whole stands for a function whose values are
> > abstractions of the kind indicated, {du'u, ni, nu} so far for sure,
> > and since those who have opinions other than mine do object the same
> > structure without any abstractor present, I suggest that we use the
> > now redundant {ka} (just {du'u} with {ce'u} in it and with the
> > disadavantage that it doesn't say what it leads to) to warn of
> > impending {ce'u} in all cases: {le ka du'u ce'u broda}, {le ka ni
> > ce'u broda}, {le ka nu ce'u broda} and (taDA) {le ka broda be ce'u} .
> > The last might takes some fiddling, since it is not always a
> > function to individuals. On the other hand, we could presumably
> > simplify the form down to {le ka broda ce'u}.
>
>If I understand correctly, you're proposing a fairly radical grammar
>change. It should be Lojbab who replies to your proposal, since he
>both respects your sagacity and, on behalf of others, is implacably
>opposed to grammar change.

Actually it requires no grammar change at all. You can have abstractions 
of abstractions. This is merely assigning meaning to some, and deassigning 
meaning to others.

But I would reject it as a violation of the Woldemar codex baseline even 
without it needing a grammar change. I haven't followed the thread so I 
don't even know what the problem is (I saw this one because you changed 
subject headings).

>I don't think we've adequately explored alternatives, because
>the rest of us are only just getting to grips with what you're
>looking for ways to express. So I'm not persuaded that a grammar
>change is called for. For instance, Lojbab's suggestion is worth
>exploring:
>
> > Not that I've come close to following this discussion, but would it be
> > easier to talk about mamta as a function if, like sumji -> su'i, you were
> > to convert mamta to an operator and use Mex
> >
> > na'u mamta ["be ce'u" or "be fa ce'u", whichever is appropriate to mark 
> the
> > value apart from the arguments]
>
>You replied to that:
> > I'm not sure. It would (I suppose -- though I can imagine all kinds
> > of weaseling going on on even this) make it clear that there is a function
> > being talked about. The problem ten is the temptation to see it as a
> > mathematical function, giving rise to mathemtatical entities as values.
>
>It would be a good outcome if we overcame the temptation, because it would
>show that mex expressions might have some utility for everyday discourse.

And indeed Mex has many non mathematical applications, and is SUPPOSED to 
be usable for formal logic expressions that aren't directly translatable 
into Lojban predicates. Some of the requirements, for example, came from 
the need to support notations that pc used in his own book on tense logic 
(the symbology in that book was daunting %^)

So any time you want formal expression and it isn't a simple predicate or 
one of the ornamentations thereof that we designed into the language, Mex 
is the way to go - or at least we hope so.

>So, if you can look charitably on my ignorance of mekso, let me sketch out
>some thoughts.
>
>1. Lojban has no way to express the mother-of function applied to an argument.

This is notationally
y=mother(x)
correct?

If so, then it is precisely mekso, and you can convert the predicate with 
ce'u as a single thing, or convert all the pieces to an Polish notation 
expression with "mamta" as the operator and 1 operand for the x2 (this 
loses the number-of-arguments semantics info since it is purely notational 
and the functions can have arbitrary numbers of arguments)

>2. Lojban's prime exemplars of functions are its mex operators, and Lojban
>provides a way to convert a selbri to operator: {na'u mamta}. (I don't see
>that we need {na'u mamta (be?) ce'u}.)

This is what I was just referring to - whether you wish to capture the 
place structure info in the conversion, or whether you want the brivla as 
an arbitrary name for the function with the number of places know only 
informally. I presumed your seeking formal semantics would require that if 
mamta has 2 places, that the function be clearly defined as having the 
appropriate domain.

>3. There seems to be no easy way to convert an operator to a sumti.

You can convert ANYTHING in Mex. You probably want to use me'o and leave 
the operands unfilled.

>Does
>{li} tolerate an operandless operator as complement -- {li na'u mamta}?
>Otherwise, {li ni'e nu'a na'u mamta} converts from operator to sumti.

You may want me'o and not li, because me'o retains the expression, whereas 
li is the evaluated expression. But LI (which includes both) takes 
anything you can say in the mex subset, sometime requiring a bracket.

lojbab
--
lojbab lojbab@lojban.org
Bob LeChevalier, President, The Logical Language Group, Inc.
2904 Beau Lane, Fairfax VA 22031-1303 USA 703-385-0273
Artificial language Loglan/Lojban: http://www.lojban.org


