lo + opaque

["John E. Clifford" <pcliffje@CRL.COM>]

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.)