From LOJBAN%CUVMB.BITNET@uga.cc.uga.edu Sat Nov 26 22:28:59 1994 Message-Id: <199411270328.AA21090@nfs2.digex.net> Date: Sat Nov 26 22:28:59 1994 From: "John E. Clifford" Subject: lo + opaque Status: RO Sorry to put you all through the pain of teaching a recalcitrant student. I have been away longer -- and it turns out, further -- than I thought. In the Logland where I wandered, thinking it was Lojban but not checking, there was this nice critter which fitted and filled a pattern, was based in formal logic and was very useful. No wonder I thought it was in Lojban! It may take me a while to get back to seeing those virtues in the real Lojban form and to figure out how to do here what was so easy there. Thank you for your patience. I sent three messages out a few days ago, all to the same automatically entered address. One came back marked "Addressee Unknown" or the equivalent. Go figure! On the chance that the bounce note is right and that you have not my latest word on opacity, here is a copy. If the note was wrong, sorry to clog your box. There are at least two problems with opaque contexts (event descriptions and those that set up satisfaction sets at least -- are there other opaque cases?). Some opaque contexts are such that we can hide the context, leaving only isolated sumti fragments from them -- subject raising. The terms from the opaque context then appear as though they were in a transparent context, when they aren'tand we make incorrect inferences as a result. I need a box" no more than "I want a unicorn" implies that there is one to be wanted or needed. For this problem we have _tu'a_ which marks raised subjects and so says "Ordinary inference rules do not apply here" (BTW, translating _da_poi_ as "there exists a", as if _zaste_ were involved sometimes at least complicates the problem.) OTOH we can sometimes make references from within these contexts that we mean to apply outside as well: "any", "a certain" (as a leaper quantifier), sometimes names, sometimes indexed descriptions. We could use to have a flag for these as well. I _think_ that this is Xorxes' _xe'e_, though, since it was presented in very different terms from what has now developed, I am not sure. If I am right, the "Pick any card would be _ko_cuxna_xe'e_ro_karda_ and "I need that box" _mi_nitcu_tu'a_xe'e_tanxe_ (or do _tu'a_ and _xe'e_ cancel eachother out -- I think the order is right: _tu'a_ identifies the opaque context and _xe'e_ escapes it.) In any case, we can always put things from outside into an opaque context, so that an established _levi_tanxe_ or name or variable presents no problems at all. It is only getting out that is a problem. But maybe we need to flag all outside-referring expressions in opaque contexts, those that come from outside as well as those that start within. A couple of people have suggested other ways of dealing with imperatives. I suppose we could extend the meaning of "true" analogically to imperatives, since there is an almost analogous adequacy criterion: "I do it" is true iff I do it "Do it" is --- iff you do it. There is the obvious difference of filling the missing subject, but the quantifier cases are probably the insurmountable problem: for all cards x, "Pick any card" is --- iff you pick x "Pick any card" is --- iff, for every card x, you pick x is even worse. The first is at least correct from right to left, the second in neither direction. I don't think that Lojban has extended the meaning of "true" nor _jutne_ in this way nor do I think it should. The other suggestions, that imperatives are somehow related to intentional predicates with event descriptions: "want" or "compel" or some such. That would be nice for my general thesis, but it is false to fact, for we often order/request etc what we do not want -- either actively loathe or passively don't care one way or the other about and so on for the other possibilities. I am afraid satsfaction sets are the best account of imperatives I know and they are obstinately disinclined to provide nice linguistic forms (which would not be equivalent to imperatives in any case.)