Return-Path: LOJBAN%CUVMB.BITNET@vms.dc.LSOFT.COM Received: from SEGATE.SUNET.SE (segate.sunet.se [192.36.125.6]) by xiron.pc.helsinki.fi (8.7.1/8.7.1) with ESMTP id KAA04812 for ; Wed, 14 Feb 1996 10:30:02 +0200 Message-Id: <199602140830.KAA04812@xiron.pc.helsinki.fi> Received: from listmail.sunet.se by SEGATE.SUNET.SE (LSMTP for OpenVMS v1.0a) with SMTP id 757AD701 ; Wed, 14 Feb 1996 9:29:53 +0100 Date: Wed, 14 Feb 1996 10:28:32 +0200 Reply-To: veion@XIRON.PC.HELSINKI.FI Sender: Lojban list From: Veijo Vilva Subject: Re: GEN: almost-PROPOSAL: intervals X-To: lojban@cuvmb.cc.columbia.edu To: Veijo Vilva Content-Length: 2058 Lines: 46 la lojbab cusku di'e > Date: Wed, 14 Feb 1996 00:55:03 -0500 > From: Logical Language Group > Subject: Re: GEN: almost-PROPOSAL: intervals > > To make for example, the NOI proposal general enough, as in Veijo's last > version, you have a relative clause, and nothing is all that clear as to > where the "ke'a" is in the relative clause, OR what the ke'a stands for. > Thus "za noi nanca lipimu ..." you could not put any of the standard > KOhA in the x1 of nanca, and have it be clear. You have to deduce or declare > a convention that a time interval there is a time interval distance. There > is no way to make thius precisely clear. The convention would be that ke'a refers to the tense property described by the preceding mod_head, i.e. time interval distance in the case of ZI and time interval duration in the case of ZEhA etc. Everything is already based on conventions, so one new convention... > And unfortunately, I can easily > envision that a construct like Veijo's latest version (was it mod_head+ > relative clause?) is so potentially flexible that people will invariably find > all sorts of interesting things to put in that relative clause, with some > inevitable semantic collision. I just made a technical feasibility study. Having 'mod_head + relative_clause' in the model which passes YACC means that all more restricted models will also pass YACC - no extra testing is required. Having thought of the matter, I actually see no reason to restrict a potential actual implementation - the ability to generate an immense variety of semantic crap is nothing new as far as the Lojban YACC grammar is concerned :-) The full model offers some really interesting possibilities if you start thinking about it with an open mind, and there might be much less pressure for amendments in the future if it were adopted instead of some limited form. -- co'o mi'e veion --------------------------------- .i mi du la'o sy. Veijo Vilva sy. ---------------------------------