Received: from mail-pz0-f61.google.com ([209.85.210.61]:33524)
	by stodi.digitalkingdom.org with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76)
	(envelope-from <lojban+bncCOTEtqyUDhChz4X3BBoEkP7tbA@googlegroups.com>)
	id 1RYpUQ-00038P-KB; Thu, 08 Dec 2011 17:43:11 -0800
Received: by dajx4 with SMTP id x4sf2674488daj.16
        for <multiple recipients>; Thu, 08 Dec 2011 17:43:00 -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=N/wsPMbE5Cb12p8JjZ72xOzcqvM/80No+uRXortXWIk=;
        b=ds/Ud31bcNocP2sOqqP++ATWw0Govfa7HgBR76fL1km2dabIgX1+CyZ+fYt+xpNgr4
         Zgj1myCNKftEAEilLPF7iDnyolixcTAMBq9Rpmo6em/NpGGq4Qwa0Hxr4d3spGPRhqne
         WsJNAzlY8iCA7VvVgERtlWYJ2infwnjVat4V0=
Received: by 10.68.74.34 with SMTP id q2mr81500pbv.2.1323394977863;
        Thu, 08 Dec 2011 17:42:57 -0800 (PST)
X-BeenThere: lojban@googlegroups.com
Received: by 10.68.26.8 with SMTP id h8ls9584519pbg.1.gmail; Thu, 08 Dec 2011
 17:42:57 -0800 (PST)
Received: by 10.68.189.233 with SMTP id gl9mr342446pbc.8.1323394977238;
        Thu, 08 Dec 2011 17:42:57 -0800 (PST)
Received: by 10.68.189.233 with SMTP id gl9mr342444pbc.8.1323394977225;
        Thu, 08 Dec 2011 17:42:57 -0800 (PST)
Received: from sdf.lonestar.org (mx.sdf.org. [192.94.73.19])
        by gmr-mx.google.com with ESMTPS id n6si8235861pbg.2.2011.12.08.17.42.57
        (version=TLSv1/SSLv3 cipher=OTHER);
        Thu, 08 Dec 2011 17:42:57 -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 pB91guIm027098
	for <lojban@googlegroups.com>; Fri, 9 Dec 2011 01:42:56 GMT
Received: from martin by gonzales.homelinux.org with local (Exim 4.75)
	(envelope-from <mbays@sdf.org>)
	id 1RYpUG-0001ZU-Cr
	for lojban@googlegroups.com; Thu, 08 Dec 2011 20:42:56 -0500
Date: Thu, 8 Dec 2011 20:42:56 -0500
From: Martin Bays <mbays@sdf.org>
To: lojban@googlegroups.com
Subject: Re: [lojban] semantic parser - tersmu-0.1rc1
Message-ID: <20111209014256.GC12304@gonzales>
References: <20111204014942.GC11790@gonzales>
 <CAO7tK2d92MaRx2tO5rfzvT97dzxfBrZ9Q8XL_kgoH7VCF+i_NA@mail.gmail.com>
 <20111204172803.GA3091@gonzales>
 <CAO7tK2ctfXMV6chvWKTLo+Rjbdgj0MdJdwQM62qN+meuT_8Ttg@mail.gmail.com>
 <1323097700.59133.YahooMailRC@web81308.mail.mud.yahoo.com>
 <CAO7tK2efsWdpGLppXjghLf=Kc1UrAzJSxKu7_PNCS_=e-VedVw@mail.gmail.com>
 <1323271781.23349.YahooMailRC@web81306.mail.mud.yahoo.com>
 <CAO7tK2f_rGg29zMmG0o-eVjjCZiETyxyM2Ki1KvGiP-vrg3szg@mail.gmail.com>
 <611800B1-334B-4D32-B782-6ED30F1E8E62@yahoo.com>
 <CAO7tK2fX+UOKQaj3bcPno4f5ycCfj58A4T0nO87jBAC4fD+JXw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="oJ71EGRlYNjSvfq7"
Content-Disposition: inline
In-Reply-To: <CAO7tK2fX+UOKQaj3bcPno4f5ycCfj58A4T0nO87jBAC4fD+JXw@mail.gmail.com>
X-PGP-Key: http://mbays.freeshell.org/pubkey.asc
X-PGP-KeyId: B5FB2CD6
X-cunselcu'a-valsi: rokci
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:googlegroups-manage+1004133512417+unsubscribe@googlegroups.com>
X-Spam-Score: -0.7 (/)
X-Spam_score: -0.7
X-Spam_score_int: -6
X-Spam_bar: /


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

* Thursday, 2011-12-08 at 13:48 -0300 - Jorge Llamb=EDas <jjllambias@gmail.=
com>:

> A somewhat separate issue is what to do with apparently unbound
> variables. The basic rule is:
>=20
> (4) Ex:P(x)  <--->  P(x)
>=20
> but again this is underspecified as to the order in which it has to be
> applied with respect to the other rules. If you want to unpack
> P(Ax,y), you get something different if you apply (1) and then (4), or
> if you apply (4) first and then (1).
>=20
> My preferred rule is that whenever you run into a variable x which is
> apparently unbound, it gets replaced by Ex, so P(x) must be read as
> P(Ex) and only then apply the unpacking rules 1, 2 and 3 in the order
> described above. But even better is to never omit the explicit
> quantifier.

If you'll excuse me tangling this thread...

It occurs to me that this indicates a simple description of the
difference between the two possible rules we were discussing for
handling bare {da} after a da-binding connective. They both have us, as
you say, replacing x by Ex whenever we run into an apparently unbound
x - the difference is just in when they run into it.

In the case of {ro da .e ko'a da}: under one rule (I) the connective causes
us to *fork*, and process the remainder of the sentence in two different
parallel contexts, so the bare {da} is run into *twice*.

For the other (II), I see two ways to imagine (and code) it: either
(a) we have a preprocessing stage which statically observes that the
bare {da} isn't going to be properly bound so adds a {su'o} to it, and
then we process as above; or
(b) we have no such preprocessing stage, but nor do we really fork in
the sense above - rather, once the connective is complete subsequent
terms are seen but once, and are applied to both arms of the connective.

(Please note that in both cases, I am assuming that all referring
constant terms do their referring prior to this algorithm; the forking
doesn't involve textual reduplication)

I do still find (I) the most conceptually intuitive, although the
results of (II) may be cleaner.

Martin

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

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

iEYEARECAAYFAk7hZ6AACgkQULC7OLX7LNZhJwCfR8ueiLJsorcIcAFkaEOUdMMj
SSsAoNgVpERxLmq3EYBHRDOQI88jmvNQ
=8RtO
-----END PGP SIGNATURE-----

--oJ71EGRlYNjSvfq7--