Re: responses to Jorge

[Bob LeChevalier <lojbab@access.digex.net>]

Jorge responds to me:
>> What may not have
>> been used significantly is "vazi" or "vuzi".
>
>What would they mean?  "zi" is a time magnitude.
>
>I think this shows partly where the confusion comes from.  In
>pre-historic times, ZI were supposed to be magnitudes both for time PUs
>and for space VAs.  PUs and VAs were somehow corresponding time and
>space tenses.
>
>This is not how things are now.  The space counterparts of PUs are
>FAhAs.  They show direction.  The space counterparts of ZIs are VAs,
>they show magnitude of displacement.

OK.  Now that I have refreshed my memory, i see this.

But then "zi" as tcita should correspond to "vi" as a tcita to be
consistent, and changing the meaning of "vi" as a tcita is pretty major,
even though:

>In actual use, {vi} is taken as the counterpart of {ca}, where the more
>"correct" would be {bu'u}.  I am not going to fight against this use of
>{vi}, which seems pretty much entrenched, but it should be recognized as
>somehow not conforming to specifications.

Actually, having checked, "vi" is normally an ellipsis for "bu'uvi", and
"zi" an ellipsis for either "bazi" or "puzi".  The thing is that you
MUST be able to interpret these things as elliptical versions of more
complete tenses, not that they have to be consistent.  Both have real
current usages as tenses on the bridi, and the usage as sumti tcita
right now is consistent with the bridi tense.  Your proposal separates
the tense usage from the tcita usage, and indeed I am not sure I see any
ellipsis that makes a lot of sense for zi marking the sumti as you
propose.

The only other case where tcita usage differs from tense/modal usage is
for the perfectives which you often complain are backwards.  But even
backwards is still a clear relationship between the tcita ZAhO and the
tense ZAhO.  "zi" as a tense doesn't seem to make a lot of sense in
terms of an ellipsized sumti, using your scheme.

>> I would probably interpret
>> "zi" as a tcita to mean elliptically puzi or bazi based on context and
>> the tagged sumti, since that is what I use the bare "zi" as a tense to
>> mean.
>
>That's the canonical interpretation, yes.  My contention is that there
>is a much more useful possible meaning for the tagged sumti, namely the
>actual magnitude.  For example:
>
>        mi ba xruti zi lei mu mentu
>        I'll be back in five minutes.

and I would just use "ba'o lei mu mintu" or more likely "ba'o le mintu
mumei".

>> Perhaps with an obviously locational sumti, I might interpret it
>> as ellipsis for vizi+FAhA i.e. a short distance away in some particular
>> unstated direction from the point.
>
>{zi} can't be used with space tenses, if I understand correctly.

OK, I got confused here.  But if "zi" was to be used as you suggest then
by correspondence "vi" as a tcita would have to label a distance.

Re the dakau/ke'a issue - OK you have convinced me that the two usages
of kau would conflict.  I do not feel ke'a is the way to go, subscript
or no.  I would rather use a new cmavo.  In any case, this one needs to
go on the issues list to be resolved.  Or rather both of them, since I
think we had been thinking both could be handled by kau under the lambda
concept. dakau should mean one or the other, and we need a universally
unambiguous way to do the other.  I don't think ke'a is good enough.

I don't understand lambda calculus in the least, but if the need in
lambda calculus is for more than one variable, THAT sounds like a good
use for a KOhA with subscripts.  Only rarely would anyone need multiple
variables.  So which of the two problems fits more closely with lambda
notation, or if both do, how could we resolve them with subscripted
variables instead of kau.

(Note for new Lojbanists/subscribers - the fact that this discussion is
grossly abstruse should not be considered threatening.  These are minor
issues and when resolved can be explained to those who aren't logic
fanatics with relatively simple usage guidelines.  Indeed, our
discussions thesse days seem to all be overly technical, which may mean
that only issues that will have no significant effect on normal usage
are really left to decide.)

lojbab