Return-Path: Received: from listmail.sunet.se by xiron.pc.helsinki.fi with smtp (Linux Smail3.1.28.1 #1) id m0s3xry-0009acC; Wed, 26 Apr 95 06:34 EET DST Received: from segate.sunet.se (segate.sunet.se [192.36.125.6]) by listmail.sunet.se (8.6.12/8.6.12) with SMTP id FAA05787 for ; Wed, 26 Apr 1995 05:32:19 +0200 Message-Id: <199504260332.FAA05787@listmail.sunet.se> Date: Tue, 25 Apr 1995 20:06:38 -0700 Reply-To: "John E. Clifford" Sender: Lojban list From: "John E. Clifford" Subject: proposals X-To: lojban list To: Veijo Vilva Content-Length: 3301 Lines: 49 On the proposed changes to Lojban. Of course, I still like the proposal to have an afterthought quantifier that leaps to the head of the prenex, though I do not much like using x-- space for it yet. I am also in favor -- on general principles -- of having afterthought everythings, so I support proposals for them as well, though I do not exactly see what they are to do. I do not see the other proposal about quantifiers, broadly speaking, namely to mark within intensional (opaque) contexts those sumti which were to be taken as referring outside that context and thus capable of being bound by external quantifiers (or, if quantifier expressions, capable of being exported). This is a piece of logical fussiness for the most part but it had the virtue in our discussions of legitimating some attempts to do such quantifying, for when this "external reference" mark comes together with the "subject raising" mark, they cancel to no mark, leaving the sumti as referring to the current realm, not the (hidden) remote one. This proposal got mixed with the after- thought quantifier proposal in some way and I failed to sort matters out intelligibly at the time. I just do not understand the continued requests for "any." I think I have counted seven proposals for dealing with that Eng- lish term in either current or moderately changed Lojban. Almost all of these cover the (remarkably vague even for a dictionary) definition that seems to be the crux. some cover the logic of it (the main Lojban concern, I suppose), other cover the psychology of it, most cover both. What is still missing? Back to logical fussiness, I do not see anything to be gained by any of the current proposals about (what must be loose- ly called) "lambda variables." For the informal use of lambda expressions, as a way of talking about the function itself rather than a particular application, we have a more than adequate set of abstractors already with good conventions about what to leave out or fill in with variables or what not. For the highly tech- nical use of lambda expressions, one variable is no where near enough, since the whole point of lambda conversion is to fill the different slots in different ways, more ore less independently of the ways the slots were filled in the expression you are sticking the lambda expression into. So, I vote "No" on lambda proposals until someone does a thorough job of explaining what we want them for and why what we have won't do it. On tensors on time and space vectors, I still like the solution which was in place a few years ago of having one form which attached to the vector marker and took a metric as sumti. I did not see Goran's proposal which may be just that come 'round again, but Jorge's of revising three terms for one purpose (and in the process apparently losing their rather useful -- Zipfean -- function) will not get my vote. pc>|83