Received: from VMS.DC.LSOFT.COM (vms.dc.lsoft.com [205.186.43.2]) by locke.ccil.org (8.6.9/8.6.10) with ESMTP id VAA28977 for ; Wed, 29 Nov 1995 21:50:09 -0500 Message-Id: <199511300250.VAA28977@locke.ccil.org> Received: from PEACH.EASE.LSOFT.COM (205.186.43.4) by VMS.DC.LSOFT.COM (LSMTP for OpenVMS v1.0a) with SMTP id C7DBD439 ; Wed, 29 Nov 1995 21:40:36 -0500 Date: Wed, 29 Nov 1995 21:40:17 -0500 Reply-To: Jorge Llambias Sender: Lojban list From: Jorge Llambias Subject: Re: TECH: PROPOSED GRAMMAR CHANGE 38: lambda via new selma'o CEhU X-To: lojban@cuvmb.cc.columbia.edu, jorge@minerva.phyast.pitt.edu To: John Cowan Status: OR X-From-Space-Date: Wed Nov 29 21:50:11 1995 X-From-Space-Address: LOJBAN%CUVMB.BITNET@UBVM.CC.BUFFALO.EDU la djan cusku di'e > Granted that no number (quantitas) is involved, nonetheless \lambda(x) is > parallel to \E x and \A x. Parallel in what sense? Ex and Ax bind the variable, i.e. together with an expression F(x) they give a proposition. The way we use the lambda variable, the expression F(x) remains open. "le ka F(x)" refers to a function of x, where x is not bound. {da} could be used for this job if it wasn't for its automatic default binding even in the absence of an explicit quantifier. {ce'u} would serve to block the automatic binding, but having {ke'a}, which is also an unbound variable in relative clauses, there is no need to get into such complications. In "da poi F(x)" the role of {ke'a} is precisely the same as that needed in "le ka F(x)". > However, Lojban Central is still restricting overloading > "ke'a"; how would {le re do} reckon a solution in which there were two cmavo, > one for relative clauses ("ke'a") and one for lambda abstraction? I would prefer that solution over the pseudo-quantifier, but I hate to see a new cmavo for something that already exists and is actually so rare. I don't think it's overloading. In any case, what's the rush? If we find in practice that {ke'a} is causing confusion, a new one can be added, but I don't see that happening. Jorge