[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: TECH: lambda and "ka" revisited

la lojbab. cusku di'e

[Private mail, edited and made public]
> What is not clear in this proposal, is whether you expect that xe'u is going
> to be normally needed, or normally ellipsized, based on your new
> understanding of Quine. 

I think that it will be normally ellipsized, but that there needs to be
a way to distinguish between a place that's bound by the abstraction
and one that's just plain {zo'e}, in critical cases.  The default is that
if x1 is empty, the {xe'u da} goes there, so "le ka dunda" is normally
the property of being a giver/of giving, and "le ka se dunda" is normally
the property of being a gift, but that doesn't HAVE to be so.

> Second - how will this interact with other quantified expressions, 
> especially in light of your proposal regarding "re nanmu " vs "re lo nanmu"
> And do you need a BOI (explict or otherwise) to separate the xe'u from the
> quantifier:
>        ?le ka xe'ure nanmu cu gletu xe'ure ninmu
> to get a little kinky perahps when contrasting with
>        ?le ka xe'ure lo nanmu cu gletu xe'ure lo ninmu 

The forms you give are semantically unmotivated (a wishy-washy way of
saying "meaningless").  The idea is that "xe'u" syntactically is an
alternative to a "real" quantifier, and typically precedes either "da"
or a selbri (in the latter case it is elliptical for "xe'u da poi selbri").
It wouldn't precede a concrete sumti, because the whole idea is that
the lambdacated sumti are semantically empty; they are just place holders
for what the outside context plugs in:  thus "doghood" is "the property
of being x such that x is a dog", where "x" is just a semantically empty

> I am uncertain that I understand how all this ties in with the prenex
> versions.  If xe'u is PA, then stupid interpretation will try to interpret it
> as a quantifier for purposes of exporting to the prenex.  Will this work, and
> be consistent with your intent in all cases?

Yes.  This allows the formal "le ka xe'u da xe'u de zo'u da gerku de" to be
abbreviated to "le ka xe'u da gerku xe'u de" by the same mechanical rules as
are used to export to/import from the prenex in other bridi.

> And of course you may not want to put it explicitly in PA,because then someone
> will ask what is xe'u + xe'u %^)

Poof.  What is ro su'i ro?

> If the ZOhU version is a different and hence rejected solution, the following
> does not apply.  If it is still under consideration (not clear in the proposal
> since you introduce several forms and then never explicitly eliminate any,
> but rather just proposae something final which may or may not overlap with
> some of the earlier options), then is there really need for a separate
> cmavo from zo'u itself.  If there were need for explicit quantification and
> things would be ambiguous, you might be able to get away with presuming
> that a first of multiple zo'u s marked xe'u usage.

I think that the second-ZOhU alternative breaks down because we aren't
allowed to have two prenexes on the same bridi.  I meant to reject that
alternative; if I wasn't explicit enough, blame it on late-evening editing.

> But even I see the probem with this now (I think).  What if you have two
> quantified variables da and de, and you wish to lambda (on?) de but "da" has
> wider scope.

No problem.  "de" would be mentioned in the local prenex (inside ka) but "da"
would not.

> What if you have da, de, and le nanmu, and wish to lambda on
> le nanmu.

Again, that makes no sense:  lambdacated sumti should be semantically
empty, or at most a "da poi", which is a variable ranging over a restricted
scope ("da poi broda" is a kind of "da" that can only refer to something
that broda's).

> PS.  Why didn't pc want you to read Quine?

Well, he said the work was fundamentally flawed, and that even Quine's
wife justified it by saying he wrote the book while he was ill.  But
be that as it may [a good relic subjunctive], it obviously heavily influenced
JCB, and is useful as a guide to JCB's intentions.

John Cowan					cowan@ccil.org
		e'osai ko sarji la lojban.