proposals

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

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 afterthought
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 English 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 loosely 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 technical 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