Re: proposals

[jorge@PHYAST.PITT.EDU]

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