Return-Path: <@FINHUTC.HUT.FI:LOJBAN@CUVMB.BITNET> Received: from FINHUTC.hut.fi by xiron.pc.helsinki.fi with smtp (Linux Smail3.1.28.1 #1) id m0qEhus-00001WC; Fri, 17 Jun 94 20:41 EET DST Message-Id: Received: from FINHUTC.HUT.FI by FINHUTC.hut.fi (IBM VM SMTP V2R2) with BSMTP id 3009; Fri, 17 Jun 94 20:41:37 EET Received: from SEARN.SUNET.SE (NJE origin MAILER@SEARN) by FINHUTC.HUT.FI (LMail V1.1d/1.7f) with BSMTP id 3006; Fri, 17 Jun 1994 20:41:32 +0200 Received: from SEARN.SUNET.SE (NJE origin LISTSERV@SEARN) by SEARN.SUNET.SE (LMail V1.2a/1.8a) with BSMTP id 8582; Fri, 17 Jun 1994 19:39:25 +0200 Date: Fri, 17 Jun 1994 18:25:44 BST Reply-To: i.alexander.bra0125@oasis.icl.co.uk Sender: Lojban list From: i.alexander.bra0125@OASIS.ICL.CO.UK Subject: Re: (kau) and (du'u) and (jei) To: lojban@cuvmb.cc.columbia.edu Content-Length: 3599 Lines: 127 la xorxes. spuda tu'a mi no'u la .i,n. di'e > > No, the property disambiguator is just plain {da}. > That was my understanding a while back, but the last version > of John's paper on abstractions says otherwise. Ouch! I haven't kept up with the latest grammar papers. I'll have to check this one out. > > (Is it time to revisit my "Desperately seeking properties" > > rant from way back at the end of August? John Cowan threatened > > to respond to the "properties" half, but to the best of my > > knowledge never did.) > Yes, please do! I think at the time I was in anti-nationality-gismu > mode, and probably wasn't reading all that was posted. You asked for it. :-) ============> Subject: TECH: Desperately seeking properties zoi glibau. Another longish technical rant. This one's in two parts, one on properties, and another on {sisku}. The latter may result in some modification or clarification of the place structure, in which case I'll pass the outcome on to lojbab. glibau. .i loi ka co'e zo'u mi ji'isku zoi glibau. Some thoughts on properties. Round about March we decided that a property was a predicate function, a function returning a truth value, so that e.g. lo ka da blanu is lambda x: blue(x) As it stands, this only handles boolean properties - either it's blue or it's not. Some of the things I think about as properties are quantitative rather than boolean. The obvious first thought is to use {ni} for these. lo ni tuple da There are two problems-to-me with this as it stands, the vagueness of {ni}, and the distinction between function and predicate. To take the latter point first, in the boolean case we have a distinction between le du'u da blanu The predication some-x is-blue and le ka da blanu the property (of-x): x is-blue but we don't appear to have a corresponding way of distinguishing quantities if we use {ni} for both. The second problem is that {ni} is quite vague about what quantity it means, which is fine in simple cases, and useful in certain other cases (e.g. {leni mi nelci ko'a}), but there are times when it would be useful to be more specific. By analogy with {du'u}, I propose that we allow {kau} to be used to specify the particular quantity of interest. (It may also have other related uses.) In fact we can already do this with {du'u}. ledu'u tu'okau da tuple mi The number of legs I have. So we could simply use a parallel construction with {ka}. lo'e kanba cu zmadu mi leka tu'okau da tuple de Goats have more legs than me. where we might want to clarify the identity of the "bound variable" with a {de zo'u} prenex. Another example, where the ability to clarify is more important. la kolin. zmadu mi leka da cmima tu'okau te mrilu liste Colin is on more mailing lists than me. I suppose this could be {leni te mrilu liste lo se cmima be da}, but it's a bit strained. If we allowed {ka ... kau ...} to denote specified quantitative properties in this way, it would leave {ni} free for the less-well-defined quantities. I think I prefer this to the other alternative I can see, which is to use {ni} irrespective of whether we mean a concrete quantity leni [tu'okau da] tuple mi or a functional one leni [de zo'u] [tu'okau da] tuple de and rely on a combination of context and the inclusion of some of the optional bits to help the audience understand what we mean. And of course these possibilities don't have to be mutually exclusive. .glibau .i pe'udo'u pinka .e'o fi ko <================= (stuff about {sisku} omitted) co'o mi'e .i,n.