Received: from mail-pz0-f56.google.com ([209.85.210.56]:65431)
	by stodi.digitalkingdom.org with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76)
	(envelope-from <lojban+bncCOTEtqyUDhDtvMT2BBoEyaiYOA@googlegroups.com>)
	id 1RULpd-0006ZT-JS; Sat, 26 Nov 2011 09:14:36 -0800
Received: by pzk6 with SMTP id 6sf1565779pzk.1
        for <multiple recipients>; Sat, 26 Nov 2011 09:14:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=beta;
        h=x-beenthere:received-spf:date:from:to:subject:message-id:references
         :mime-version:content-type:content-disposition:in-reply-to:x-pgp-key
         :x-pgp-keyid:x-cunselcu'a-valsi:user-agent:x-original-sender
         :x-original-authentication-results:reply-to:precedence:mailing-list
         :list-id:x-google-group-id:list-post:list-help:list-archive:sender
         :list-subscribe:list-unsubscribe;
        bh=obf8sGfjxgCF5chJ1HVAUxQMYOps7u3xUXSnqiTbzZs=;
        b=NaCDj3BFGIreBgxCtxCQXyko2aaCd6UqQbpCnA73gypM8ukTOp8DBfOlx7DRukEMRN
         YBjTK13KphrGE9QNzRFNhIfxnebswmPlPqBfCWiEwdFaqgWB5Ljl9CwgQSwtESQbx/8y
         ycVh6kO4vkNIU6xtbuzHkKNxIxSbC8sizR64Q=
Received: by 10.68.12.36 with SMTP id v4mr1751739pbb.4.1322327661104;
        Sat, 26 Nov 2011 09:14:21 -0800 (PST)
X-BeenThere: lojban@googlegroups.com
Received: by 10.68.121.5 with SMTP id lg5ls7019313pbb.5.gmail; Sat, 26 Nov
 2011 09:14:20 -0800 (PST)
Received: by 10.68.15.105 with SMTP id w9mr16171044pbc.7.1322327660461;
        Sat, 26 Nov 2011 09:14:20 -0800 (PST)
Received: by 10.68.15.105 with SMTP id w9mr16171043pbc.7.1322327660452;
        Sat, 26 Nov 2011 09:14:20 -0800 (PST)
Received: from sdf.lonestar.org (mx.sdf.org. [192.94.73.19])
        by gmr-mx.google.com with ESMTPS id lj6si4590703pbb.1.2011.11.26.09.14.20
        (version=TLSv1/SSLv3 cipher=OTHER);
        Sat, 26 Nov 2011 09:14:20 -0800 (PST)
Received-SPF: pass (google.com: best guess record for domain of mbays@sdf.org designates 192.94.73.19 as permitted sender) client-ip=192.94.73.19;
Received: from gonzales.homelinux.org (root@sverige.freeshell.org [192.94.73.4])
	by sdf.lonestar.org (8.14.5/8.14.3) with ESMTP id pAQHEJXT013944
	for <lojban@googlegroups.com>; Sat, 26 Nov 2011 17:14:20 GMT
Received: from martin by gonzales.homelinux.org with local (Exim 4.75)
	(envelope-from <mbays@sdf.org>)
	id 1RULpT-0006TS-G5
	for lojban@googlegroups.com; Sat, 26 Nov 2011 12:14:19 -0500
Date: Sat, 26 Nov 2011 12:14:19 -0500
From: Martin Bays <mbays@sdf.org>
To: lojban@googlegroups.com
Subject: Re: [lojban] semantic parser - tersmu-0.1rc1
Message-ID: <20111126171419.GA15113@gonzales>
References: <20111124044118.GF6112@gonzales>
 <CAO7tK2cfhJtrvLX1S6Mga_CJU2nLyt96_4DR=ygJksH3ixaamg@mail.gmail.com>
 <20111125195038.GA29512@gonzales>
 <CAO7tK2ezxrDKHEDQx1k7O1+E_FsviPXYOK=R8aU3xVy2C4kb6g@mail.gmail.com>
 <20111126012512.GA6702@gonzales>
 <CAO7tK2euHY7snwkb2L68spGHYpX=mAiVXYYjXs0Aws+3=JZdEQ@mail.gmail.com>
 <20111126040757.GA17974@gonzales>
 <CAO7tK2dJc8y14v8iVZ-3Y7WxW55JJ5-qv4f841aVy=AmxnqJ-w@mail.gmail.com>
 <20111126150912.GB27177@gonzales>
 <CAO7tK2cMYxgWMJWCLL0_WdH25h3nzKDrh9BAKV3_2RQSf2VqFw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="vtzGhvizbBRQ85DL"
Content-Disposition: inline
In-Reply-To: <CAO7tK2cMYxgWMJWCLL0_WdH25h3nzKDrh9BAKV3_2RQSf2VqFw@mail.gmail.com>
X-PGP-Key: http://mbays.freeshell.org/pubkey.asc
X-PGP-KeyId: B5FB2CD6
X-cunselcu'a-valsi: fancu
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Original-Sender: mbays@sdf.org
X-Original-Authentication-Results: gmr-mx.google.com; spf=pass (google.com:
 best guess record for domain of mbays@sdf.org designates 192.94.73.19 as
 permitted sender) smtp.mail=mbays@sdf.org
Reply-To: lojban@googlegroups.com
Precedence: list
Mailing-list: list lojban@googlegroups.com; contact lojban+owners@googlegroups.com
List-ID: <lojban.googlegroups.com>
X-Google-Group-Id: 1004133512417
List-Post: <http://groups.google.com/group/lojban/post?hl=en_US>, <mailto:lojban@googlegroups.com>
List-Help: <http://groups.google.com/support/?hl=en_US>, <mailto:lojban+help@googlegroups.com>
List-Archive: <http://groups.google.com/group/lojban?hl=en_US>
Sender: lojban@googlegroups.com
List-Subscribe: <http://groups.google.com/group/lojban/subscribe?hl=en_US>, <mailto:lojban+subscribe@googlegroups.com>
List-Unsubscribe: <http://groups.google.com/group/lojban/subscribe?hl=en_US>, <mailto:lojban+unsubscribe@googlegroups.com>
X-Spam-Score: -0.7 (/)
X-Spam_score: -0.7
X-Spam_score_int: -6
X-Spam_bar: /


--vtzGhvizbBRQ85DL
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

* Saturday, 2011-11-26 at 13:26 -0300 - Jorge Llamb=EDas <jjllambias@gmail.=
com>:

> On Sat, Nov 26, 2011 at 12:09 PM, Martin Bays <mbays@sdf.org> wrote:
> >
> > How can the syntax be suggesting that linkargs but not selbri tags get
> > tighter scope than tailterms?
>=20
> Because linkargs aredefinitely internal to the selbri, while selbri
> tags are for all intents and purposes external to the selbri (weird
> guhek cases aside

(would you agree that "guhek selbri-3 gik selbri-6" is a more sensible
grammar of guheks than the official one, by the way? I spent some time
trying to make sense of the official "guhek selbri gik selbri-6", but
failed - mostly because of the weird interactions with {co})

> ). Consider "na'e ke broda be na ku (ke'e)" for example.

That's a very good point.

I actually was, until I changed it a few days ago, handling selbri3
after tailterms. What made me change was {broda be da brode ro da} - it
seems counterintuitive to have the first {da} in the scope of the
second, which is what I seemed to be forced to do when handling
tailterms first.

Do you see another way to avoid that? Or do you consider it correct?

> >> Yes, but I'm just parsing gi'e, na and selbri tags before tail terms
> >> rather than leaving them for last. That's what the syntax suggests,
> >> and I just don't see the advantage of doing otherwise.
> >
> > For giheks and ijeks, an argument might be that they are afterthought
> > connectives, so should be usable in situations where you had not
> > considered when starting the sentence that you were going to want to add
> > the connective. If you introduce a quantifier (or sumti connective)
> > during the first connectant, you may want it to scope over the second
> > connectant - and since you hadn't planned on expressing the second
> > connectant at all, you won't have had the foresight to put the
> > quantifier in a prenex.
>=20
> But by the same token you may not have had the foresight that you
> would want a qantifier or sumti connective that does not scope over
> the gihek. Either way you'd have to start over, so we need to compare
> which situation is more normal/frequent, and which structure is more
> natural.

Fair. But I'm afraid I do intend to let conservatism take priority in
this case, at least for now.

> > As for having {na broda da} work differently from {na ku broda da}...
> > one argument would simply be that it allows you to efficiently get at
> > meanings which would otherwise be complicated to express.
>=20
> You can use "na'e (ke)" instead of "na" to get your meaning easily,

You have {na'e} giving logical negation?

> but I suppose you could make your argument with tags rather than with
> "na".
>=20
> > e.g. suppose
> > we want to add negations to modify
> > {broda da gi'e brode vau de}
> > to have the first conjunct be
> > EX x1. EX x2. !broda( ,x1,x2) .
>=20
> Are you using your gi'e-rule, or mine?

It shouldn't matter for the purposes of this example.

> With your gi'e-rule, my na-rule makes little sense. We both agree that
> na is subordinate to gi'e, so if gi'e has tight scope, na must too.

Hold on. I understand your gi'e rule as giving e.g.
na broda gi'e na brode da
-> ge na broda da gi na brode da ,
so there's still the issue of whether those {na}s scope over the {da}s.

> > With your {na} rule, it seems you would have to make it
> > {broda da gi'e nai brode vau de na ku} .
> > With mine, it's just
> > {na broda da gi'e brode vau de} .
>=20
> It's clear that one rule will allow some things being shorter, and
> another rule will allow other things being shorter. I don't think a
> single example with no semantic content will be convincing either way.

Sure. But note that I can get your rule by replacing the {na} with
a {na ku} after the selbri, so just one syllable extra. Going the other
way seems harder in some cases - e.g. the example I just gave.

> > Another argument would involve your agreeing with me that
> >
> > broda je brode da
> > Prop: EX x1. (broda( ,x1) /\ brode( ,x1))
> >
> > is correct... do you?
>=20
> I agree it's EX x1 brodi(x1), and what you offer for brodi is probably
> the obvious choice. But tanru are weird, so I won't commit to it. In
> any case, I suppose you don't need the exact form of "brodi" for your
> argument, but I don't consider na and tag to be part of the tanru, so
> selbri attached "na" is different from tanru-making "je".

Hmm. Why do you call this a tanru? The relevant grammar for
selbri connection is selbri-4 through selbri-6. It's true that the usual
use (and the only documented use, to my knowledge) of selbri connection
is in a seltau, but I don't see why we should consider the connectives
themselves as anything more complicated than boolean operators.

Martin

--vtzGhvizbBRQ85DL
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)

iEYEARECAAYFAk7RHmsACgkQULC7OLX7LNbR4QCbBelCej/omGIDpqFzn9GsuXpO
9gUAoKFAsJRvqyWkn8RA/sbX9R+1Jn9d
=FfCQ
-----END PGP SIGNATURE-----

--vtzGhvizbBRQ85DL--