From LOJBAN%CUVMB.BITNET@UGA.CC.UGA.EDU Thu Jun 23 15:56:31 1994
Message-Id: <199406231956.AA06322@nfs1.digex.net>
Date: Thu Jun 23 15:56:31 1994
Reply-To: jorge@PHYAST.PITT.EDU
Sender: Lojban list <LOJBAN@CUVMB.BITNET>
From: Jorge Llambias <jorge@PHYAST.PITT.EDU>
Subject:      Re: TECH: nunsucta sidbo
X-To:         lojban@cuvmb.cc.columbia.edu
To: Bob LeChevalier <lojbab@access.digex.net>
Status: RO

la i,n cusku di'e

> Some ideas for identifying focus points, "objects of interest",
> in abstractions.
>
> Option 1:  The direct approach
>
> I've tried expressing some of these "indirect question"-type
> phrases without using {kau}.

Why would we want to do that? The indirect questions are the basic
meaning of {kau}, I hope we're not changing that.

I'm not sure I understand what {lu'e} means, but the other example:

>         mi djuno le te kancu be le'i klama bele zarci
>
> Even if we can ignore the suggestion of an agent in {kancu},
> this is starting to get clumsy, and quantities are one of the
> things we need good expressions for.

Also, I don't think le seldjuno can be a number, it has to be a du'u.

> There may be a way of getting this to work, which would free
> up {kau} for other things such as the "property of X"
> construction, but it's not clear at the moment.

I wouldn't abandon this use of {kau}, which is the most useful
as far as I can tell.


> Option 2:  Tweak the status quo
>
> Option 2a:  More UI tags
>
> Scrape up another cmavo or two, and/or invent a pseudo-scale
> for {kau} (kau-kaucu'i-kaunai, or whatever), to extend the
> possibilities.

I don't like this option either. I think it just causes more confusion.

> While we're at it, we might want to allocate a LUhE for
> "the number of elements in the set".

I think that might be useful.

> Option 2b:  {kau} vs. non-{kau}
>
> Of course there's always my previous idea of using an
> un-{kau}-ed variable for the lambda-binding and {kau}
> for the quantity of interest.

I think this is the best. There is no conflict with indirect questions,
because one uses {du'u} and the other {ka}. For nested abstractions,
of either or mixed kind, use subindices, or (better in my opinion),
doubled {kau}.

> Option 3:  Extend the prenex/quantifier construction

I'm not sure I understand all this. Any suggestions where I can
read some introduction to this lambda-binding business?

I think the best is to use {du'u ... kau ...} for indirect questions,
{ka ... kau ...} as in your original idea, and look for something else
to use with {zmadu} and {mleca}, if the simple variable doesn't suffice.


> What's happened to {du'u}, {ka} and {ni} in all this?
> I'm not sure - they seem to be mutually redundant,
> but we might retain them all for convenience.

I don't see this. {ni} may be redundant to {ka ...xokau ...}, and
{jei} seems to mean {du'u xukau} in all the examples I've seen,
but how are {du'u} and {ka} mutually redundant?

Jorge