Return-Path: Received: from listmail.sunet.se by xiron.pc.helsinki.fi with smtp (Linux Smail3.1.28.1 #1) id m0s4FXz-0009aeC; Thu, 27 Apr 95 01:27 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 AAA28667 for ; Thu, 27 Apr 1995 00:24:44 +0200 Message-Id: <199504262224.AAA28667@listmail.sunet.se> Date: Wed, 26 Apr 1995 18:27:28 EDT Reply-To: jorge@PHYAST.PITT.EDU Sender: Lojban list From: jorge@PHYAST.PITT.EDU Subject: Re: proposals X-To: lojban@cuvmb.cc.columbia.edu To: Veijo Vilva Content-Length: 5916 Lines: 133 la pycyn cusku di'e > 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. That's a temporary assignment. If it's approved, it gets a real cmavo. > 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. You don't like my examples? Some of them were: mi prami la maris du'ibo la djan I love Mary and equally John. mi fa'u do dei ciska gifa'u tcidu I respectively you write respectively read this. > 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). I thought that was what the leaper was supposed to do. > 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'm confused then. The leaper is not supposed to change prenexes? Only to jump to the head of its corresponding prenex? Actually, I like this much more than the mega-leaper, but its use is much more limited. It doesn't do what And and I thought it did. > 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? Its conciseness. > 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." Probably it is not a good idea to use the term "lambda variable". What we need is something much more prosaic. > 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. None of those two uses are of any interest to me. > 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. I want to say "John gives more than Mary". I could say: la djan zmadu la maris le ka dunda But that could also mean "John is given more than Mary". To disambiguate, using {ke'a}: la djan zmadu la maris le ka ke'a dunda John is more than Mary in property "____ gives something to someone". la djan zmadu la maris le ka dunda fi ke'a John is more than Mary in property "Someone gives something to ____". If there is another way to do this, I don't know it. I don't know if this should be called a lambda variable either, but we need something like it. Since my proposal doesn't really require to change anything, I intend to use it in the rare occasions when it would be needed, and risk being misunderstood by those who don't approve. (Currently, {ke'a} is meaningless in those sentences.) > 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. Could you explain this further? I have no idea what "tensors" in the sense I understand them have to do with this. > 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. I do not propose to revise the terms themselves, only what is the interpretation of the tagged sumti. I'm not sure what you mean by their useful Zipfean function. What can you use pure ZI as tcita for? They have never been used in any text I've seen. Neither have the VAs, with the exception of {vi}, but this one is used with the meaning of {bu'u} ("at, coincident with") instead of its own meaning ("a small distance from"). Although the VAs (unlike the ZIs) may be useful, they can easily be supplanted by existing FAhAs. In any case, this is also a mere matter of interpretation. It won't hurt to have both competing interpretations together, and let the one that gets used the most survive. The only real "changes" are the grammar extensions, and I'm glad you agree with them. Jorge