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 #14) id m0pfYQ2-0000R2C; Sat, 12 Mar 94 20:28 EET Message-Id: Received: from FINHUTC.HUT.FI by FINHUTC.hut.fi (IBM VM SMTP V2R2) with BSMTP id 7320; Sat, 12 Mar 94 20:28:01 EET Received: from SEARN.SUNET.SE (NJE origin MAILER@SEARN) by FINHUTC.HUT.FI (LMail V1.1d/1.7f) with BSMTP id 7317; Sat, 12 Mar 1994 20:28:01 +0200 Received: from SEARN.SUNET.SE (NJE origin LISTSERV@SEARN) by SEARN.SUNET.SE (LMail V1.2a/1.8a) with BSMTP id 1523; Sat, 12 Mar 1994 19:26:59 +0100 Date: Sat, 12 Mar 1994 13:28:28 EST Reply-To: jorge@PHYAST.PITT.EDU Sender: Lojban list From: Jorge Llambias Subject: Re: Even Madder (A no-go :-) X-To: lojban@cuvmb.cc.columbia.edu To: Veijo Vilva Content-Length: 3115 Lines: 85 Veijo joins in the fun: > It occurred to me last night that -- had we the option -- it would > be possible to construct a system of connectives which would be > completely regular and fulfill all the requirements except perhaps > that of maximal brevity. It would have no overloading and still > utilize a minimal number of cmavo. I don't agree that overloading, as you are defining it, is a problem. The connectors retain their meaning when connecting different types of objects. The result is different because the connected objects are different, not because the connectors mean different things. > The structure would be: > > [gi operand-type connective] operand1 operand-type connective > operand2 The problem with this is that you could use, say {ja} in the prenex and {je} in the middle, and what would that mean? I think that the whole point of forethought vs. afterthought is to be able to specify the connection first, or in the middle. (We could come up with a proposal to allow "final connection" too, but better not... :) If you wanted a different connective for each, you could use: gije ..... gi ..... ..... gije .... guje ..... gu ..... ..... guje .... gaje ..... ga ..... ..... gaje .... etc. one for each type of connection (tanru, sumti, bridi, bridi-tail, and paragraph if you want). But that would not be more clear than "overloading", because you'd be giving the vowels two different interpretations: which logical connective, when used with "j", and which type of connection, when used with "g". It would in fact be much more confusing. As it is now, GA is used for most forethought connection, so that the "overloading" is already there. {je} is also used for both bridi and tanru connection. Yet nobody is confused by the overloading, because the surrounding text makes it immediately clear what type of connection is being used. To me, bridi and bridi-tail connection are not really two different concepts, so to have different words for them is an artificial distinction. Sumti connection is different from bridi connection (although in the case of the logicals, you can expand from one to the other), and tanru connection is a third type. But the distinction is given by the elements being connected, not by the connectors themselves, which keep their meaning. > I know this system doesn't stand a chance but I wanted to present > it to give you some food for thought :-) You did, thanks :) > BTW. is there a zo'e type and/or vague connective? Yes, {do'e} of selmaho BAI. Like all tags, it can be used as a connective, although not everywhere. It's restricted to forethought connection {do'egi....gi....}, and bridi afterthought {.... .ido'ebo.....}. My proposal would probably (I don't know if John YACC-checked this one) allow {.... gido'ebo ....} as well. Now it can't be used with bridi or tanru afterthought, but I'm not sure why, since {mi do'ebo do} doesn't seem to conflict with anything, and neither does {blanu do'ebo xunre}. This might be material for a MAD PROPOSAL NUMBER 5. > > co'o mi'e veion > co'o mi'e xorxes