From pycyn@aol.com Mon Sep 10 06:12:04 2001 Return-Path: X-Sender: Pycyn@aol.com X-Apparently-To: lojban@yahoogroups.com Received: (EGP: mail-7_3_2_1); 10 Sep 2001 13:12:03 -0000 Received: (qmail 16283 invoked from network); 10 Sep 2001 13:09:21 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 10 Sep 2001 13:09:21 -0000 Received: from unknown (HELO imo-d10.mx.aol.com) (205.188.157.42) by mta1 with SMTP; 10 Sep 2001 13:09:20 -0000 Received: from Pycyn@aol.com by imo-d10.mx.aol.com (mail_out_v31_r1.4.) id r.86.f4fbbc1 (3891) for ; Mon, 10 Sep 2001 09:08:45 -0400 (EDT) Message-ID: <86.f4fbbc1.28ce155d@aol.com> Date: Mon, 10 Sep 2001 09:08:45 EDT Subject: Re: [lojban] the set of answers To: lojban@yahoogroups.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_86.f4fbbc1.28ce155d_boundary" X-Mailer: AOL 6.0 for Windows US sub 10535 From: pycyn@aol.com X-Yahoo-Message-Num: 10614 --part1_86.f4fbbc1.28ce155d_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 9/10/2001 1:57:48 AM Central Daylight Time, a.rosta@dtn.ntl.com writes: > but in {ko'u fo'u frica lo du'u ce'u prami ma kau} (in standard > usage), there are two variables: {ko'u fo'u frica lo du'u X prami Y}. > X is restricted to Dubya and Jeb (do we *have* to use Bushes in our > exsmples??) and Y ranges freely. By my analysis of Q-kau, Y is > underlyingly ce'u -- ordinary unrestricted woldemarian ce'u. So > although I could accept your story that X is a contextually restricted > ce'u, this leaves us with free and contextually restricted ce'u in the > same bridi, and with no way to tell them apart (in logical form). Maybe > something like > > la dybiyb la tcelsik frica lo du'u ce'u goi fo'o zo'u ce'u -extension > lo du'u ce'u mamta fo'o > > Well, the {makau} {ce'u} is restricted, too -- maybe more so -- since it has to generate *answers* and not every possible value will apply (indeed, generally most will not). Further, unlike the "bound" {ce'u}, the restrictions tend to be implicit rather than overt. My objects to counting {makau} as {ce'u} are two: 1) it overlooks the relation to the other interrogatives ({xukau, mokau, ...} which behave in the same way, 2) it gives a less useful spin on the interpretation of {makau} expressions. Although the difference between a function and a set is nominal in this case, thinking of a set of answers and pulling items out it, makes for clearer discussions than thinking about a function on a function does. --part1_86.f4fbbc1.28ce155d_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 9/10/2001 1:57:48 AM Central Daylight Time,
a.rosta@dtn.ntl.com writes:


but in {ko'u fo'u frica lo du'u ce'u prami ma kau} (in standard
usage), there are two variables: {ko'u fo'u frica lo du'u X prami Y}.
X is restricted to Dubya and Jeb (do we *have* to use Bushes in our
exsmples??) and Y ranges freely. By my analysis of Q-kau, Y is
underlyingly ce'u -- ordinary unrestricted woldemarian ce'u. So
although I could accept your story that X is a contextually restricted
ce'u, this leaves us with free and contextually restricted ce'u in the
same bridi, and with no way to tell them apart (in logical form). Maybe
something like

 la dybiyb la tcelsik frica lo du'u ce'u goi fo'o zo'u ce'u -extension
 lo du'u ce'u mamta fo'o

which suggestion is made largely fumbling in the dark


Well, the {makau} {ce'u} is restricted, too -- maybe more so -- since it has
to generate *answers*  and not every possible value will apply (indeed,
generally most will not).  Further, unlike the "bound" {ce'u}, the
restrictions tend to be implicit rather than overt.  
My objects to counting {makau} as {ce'u} are two: 1) it overlooks the
relation to the other interrogatives ({xukau, mokau, ...} which behave in the
same way, 2) it gives a less useful spin on the interpretation of {makau}
expressions.  Although the difference between a function and a set is nominal
in this case, thinking of a set of answers and pulling items out it, makes
for clearer discussions than thinking about a function on a function does. --part1_86.f4fbbc1.28ce155d_boundary--