Return-Path: Received: from SEGATE.SUNET.SE by xiron.pc.helsinki.fi with smtp (Linux Smail3.1.28.1 #1) id m0tNUBE-0000ZUC; Thu, 7 Dec 95 02:27 EET Message-Id: Received: from listmail.sunet.se by SEGATE.SUNET.SE (LSMTP for OpenVMS v1.0a) with SMTP id 9D71646C ; Thu, 7 Dec 1995 1:27:19 +0100 Date: Wed, 6 Dec 1995 19:12:38 -0500 Reply-To: Jorge Llambias Sender: Lojban list From: Jorge Llambias Subject: Re: TECH: new cmavo "ju'e" To: lojban@cuvmb.cc.columbia.edu, jorge@minerva.phyast.pitt.edu Content-Length: 3826 Lines: 90 la djan cusku di'e > Using this cmavo solves two problems: it eliminates the need for Jorge's > proposed change X1, It makes much more verbose what could be made simple. I don't understand why that would be preferrable. > and it allows a kind of compression that Veijo was > talking about last year that never got taken up. That's good, but why not let {jo'u} do that job? It already seems to be a pretty much unspecified connective. > However, Lojban Central feels that having compounder selma'o > involving "stag" is dangerous unless there is both a beginning and an > as in "I stag BO", "ek stag BO", "gihek stag BO", and the like; there > might be a hidden ambiguity involving a stag followed by a non-compounded > BO, and nothing except experimentation (thought or computer) can pick > up such ambiguities. Are Lojban Central's feelings really a good reason to oppose "stag BO"? Why not do the experimentation? I don't see what the hidden ambiguity could be. la lojbab cusku di'e > The complex grammar of JOI makes errors in use and resulting scope likely > unless the proper terminators are used. You keep making this claim, which seems unfounded to me. Could you give an example sentence showing how this could happen? > The proposed usage of stag or stag-BO as a connective, without a preposed > connective scope marker, would add an infinite set of cmavo-compounds to JOI, Not infinite, unless you mean use of subscripts. > and they would be difficult to resolve on the fly since they make use of > the BAI words that already have two other usages with different scopes > (sumti tcita and selbri inflection). How do you explain then that nobody has had any trouble understanding me when I use them? And why are they easier to resolve when compounded with a JOI, given that the other usages are still there? > Just as Jorge's proposal to allow JE the full range of usage of JOI is > unacceptable then, so is a major increase of JOI-scoped connectives, But why is it unacceptable? You take it as a given that it is unacceptable but you haven't explained why. You say it would be dangerous and confusing but you don't give an example of how it could cause danger or confusion. Why not let usage decide. If people are confused they will not use them. If they find it natural (as I do) then they will use them. > especially since there already IS a means to connect using causals or other > BAIs in after thought: we insert the BAI/stag in between a connective > of the right scope and BO/KE. Which connective do you use for {ba'ibo}? > I would normally have done this using ".e ri'a bo", but Cowan convinced > me last > night that using a specifica logical connective like ".e" is logically > risky - a causal does not necessarily want to claim ".e" truth conditions. Other BAIs are even less likely to want {.e}. For example {mau}, if you want to make only the comparative and not the two absolute claims. > Using JOI, with its > overstretched scope rules is dangeorous and confusing, ESPECIALLY when the > problem being posed is specifically one of scope. Again I would like to see examples. Why is it dangerous and confusing? I'm not sure how scopes enters into all this, either. > I am thus RELUCTANTLY conceding to John's proposal for ju'e BECAUSE it makes > no grammar change and uses only one cmavo, and more so, because it preserves > the existing principle of clear scope marking in afterthought connection. I'm not sure what that existing principle is, could you ellaborate? > I will note that the proposal is NOT a complete solution in any case, either > for Veijo's compression or the causal problem in general. There is no JOI > construct as counterpart to GIhEKs and GUhEks, Change X2 takes care of the giheks. If it was up to me I would eliminate the guheks altogether. Jorge