From @uga.cc.uga.edu:LOJBAN@CUVMB.BITNET Mon Oct 5 08:42:07 1992 Received: from uga.cc.uga.edu by MINERVA.CIS.YALE.EDU via SMTP; Mon, 5 Oct 1992 08:42:07 -0400 Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2) with BSMTP id 8160; Mon, 05 Oct 92 08:40:40 EDT Received: by UGA (Mailer R2.08 PTF008) id 4365; Mon, 05 Oct 92 08:40:38 EDT Date: Mon, 5 Oct 1992 12:57:18 BST Reply-To: I.Alexander.bra0122@oasis.icl.co.uk Sender: Lojban list From: I.Alexander.bra0122@OASIS.ICL.CO.UK Subject: TEXT.ADV la me ge'o ly. velkanji X-To: lojban@cuvmb.cc.columbia.edu To: Erik Rauch Status: RO X-Status: Message-ID: Inspired by a combination of Nick's mex piece and a book I've started reading called "Truth and Modality for Knowledge Representation" by Raymond Turner, I decided to try my hand at some Lambda Calculus in Lojban. cy. goi (me'o ma'o ge'o ly. boi xy. ma'o fy. ma'o xy. boi xy. lo'o) ga'e .ybu goi (li ma'o ge'o ly. boi fy. ma'o cy. boi cy. lo'o) ro fy. zo'u li ma'o ga'e .ybu boi fy. du li ma'o cy. boi cy. lo'o li ma'o fy. ma'o cy. boi cy. lo'o (to fi'o jarco tadji lepu'u favgau lenu le funca po'u le pamoi meksypau cu se sumti le remoi meksypau toi) li ma'o fy. ma'o ga'e .ybu boi fy. This seems remarkably opaque (even if you know what's going on! - but then Lambda Calculus isn't easy going even in it's more usual symbolic forms). The first problem is that _everything_ is a function, at least in the pure Lambda Calculus. Mex isn't designed to work this way. There's no easy way to turn the result of a mex expression (an operand) into an operator. I've in a sense fudged the issue by assigning the letteral {cy.} to a part of the expression, which is just about practical in this comparatively short example, but even here it would have helped the demonstration if I could have substituted the expansion of {cy.} as an intermediate step. I tried {na'u me li ... lo'o} as a way of turning a mex expression into an operator, but I didn't like it. I don't >want< {na'u me } to mean "the operator which is associated with " - it ought to mean "the operator 'is associated with '", which is a mex predicate returning a truth value. I'm not sure whether to propose a cmavo {xa'u} which turns a mex operand into an operator, which would require a grammar change, or a cmavo {xe'i} (in ma'okle ME) which means "the selbri _identified by_ ", so that {xe'i di'u} would be (approximately) equivalent to {go'i}, and {xe'i li ma'o ge'o ly. boi xy. ne'o xy.} would be the same as {nu'a ne'o} - "x1 is the factorial of x2". (Note that since the latest gismu list changed the place structure of {cmavo}, {se cmavo} no longer means "grammatical category", but "word exemplifying a grammatical category". We still have the option, of course, of _defining_ {selma'o} to mean what it used to, or we could use something like {ma'okle} instead.) This turns up problem number two, which is the rather odd mixture of {li} and {me'o} in the prenex. The definition of {cy.} has to be a {me'o} - it can't be evaluated, since it contains the free variable {fy.}. The definition of {ga'e .ybu}, zu'unai, feels like it ought to be evaluted. ta'o I've used {ge'o ly.}, without definition, as the lambda operator, which is syntactically a prefix (forethought) operator taking two arguments, the first a letteral string, and the second a mex expression, producing the function of the first argument whose result is the value of the second argument. All other operators (also forethought) are functions of the Lambda Calculus taking a single argument and producing a result which is a function. This is the common "curried" form of the calculus. (Note that the second argument of {ma'o ge'o ly.} is essentially an _unevaluated_ expression, but there's no way to indicate that.) Finally the problem of talking about "applying a function to its arguments" and "expanding the application". My suggestion is given above - alternative recommendations are welcome. Iain.