From lojbab@lojban.org Fri Oct 05 18:51:24 2001 Return-Path: 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 ; 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: Subject: RE: [lojban] On functions to various types of things. In-Reply-To: References: <106.68ac9b5.28ece37d@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed From: "Bob LeChevalier (lojbab)" X-Yahoo-Message-Num: 11386 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