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 m0r7vR2-00006rC; Thu, 17 Nov 94 03:14 EET Message-Id: Received: from FINHUTC.HUT.FI by FINHUTC.hut.fi (IBM VM SMTP V2R2) with BSMTP id 9630; Thu, 17 Nov 94 03:15:01 EET Received: from SEARN.SUNET.SE (NJE origin MAILER@SEARN) by FINHUTC.HUT.FI (LMail V1.1d/1.7f) with BSMTP id 9626; Thu, 17 Nov 1994 03:15:00 +0200 Received: from SEARN.SUNET.SE (NJE origin LISTSERV@SEARN) by SEARN.SUNET.SE (LMail V1.2a/1.8a) with BSMTP id 0128; Thu, 17 Nov 1994 02:11:50 +0100 Date: Wed, 16 Nov 1994 20:10:17 EST Reply-To: jorge@PHYAST.PITT.EDU Sender: Lojban list From: Jorge Llambias Subject: Re: Cowan's summary: opacity and sumti-raising X-To: lojban@cuvmb.cc.columbia.edu To: Veijo Vilva Content-Length: 922 Lines: 27 > As for whether "mi sisku le mi cukta" should be possible, I think > either > (a) it is possible & means "try to find" & because the event > abstraction is implicit the Lojban rules mean that it is > always transparent, so "mi sisku lo cukta" must mean > "there is a book I'm trying to find". > (b) it is impossible, and the x2 must be a "lenu...". > > I prefer (b), but the status quo wd appear to be either (a) or > confusion. > > ---- > And The status quo seems to be neither of them, but: (c) it is impossible, and the x2 is a {le ka...}, where the meaning is x1 looks for something (not quantified, thus possibly an opaque reference) that has property x2. There is no place for the looked for object. I could understand this if it never made sense to have an object being looked for, but it does make sense, so I don't see the need to forbid this simple expression. Jorge