From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Rock Newsgroups: gmane.lisp.guile.user Subject: Guile 1.9 series, unquote and unquote-splicing not up-to-date. Date: Tue, 14 Dec 2010 17:39:22 +0100 Message-ID: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=0015175cdefa80db5f0497617641 X-Trace: dough.gmane.org 1292344788 29292 80.91.229.12 (14 Dec 2010 16:39:48 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 14 Dec 2010 16:39:48 +0000 (UTC) To: guile-user@gnu.org Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Tue Dec 14 17:39:44 2010 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PSXuh-0001pP-Um for guile-user@m.gmane.org; Tue, 14 Dec 2010 17:39:44 +0100 Original-Received: from localhost ([127.0.0.1]:57547 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PSXuh-00039q-8Z for guile-user@m.gmane.org; Tue, 14 Dec 2010 11:39:43 -0500 Original-Received: from [140.186.70.92] (port=55270 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PSXuS-0002zt-HI for guile-user@gnu.org; Tue, 14 Dec 2010 11:39:37 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PSXuO-0001c4-3I for guile-user@gnu.org; Tue, 14 Dec 2010 11:39:25 -0500 Original-Received: from mail-qy0-f176.google.com ([209.85.216.176]:58113) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PSXuN-0001bd-Vc for guile-user@gnu.org; Tue, 14 Dec 2010 11:39:24 -0500 Original-Received: by qyk10 with SMTP id 10so895217qyk.0 for ; Tue, 14 Dec 2010 08:39:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=eskGzNE+xi3gIwAKM/E1hc44n6+EDhNwhkMz4r5P+ec=; b=NiOjk1VbUdHUzDY9z0mHlikR2t8k/2njVevVgM9nl0pBeatYzC89vvs7S8u+aQtanj E5wS4EO1P8gZzDo6RL2h8JL5CAR11XZhPDTodvJ8RZTNW9qSF4AzTan/UcB+bJG/N61J T7pF3NS//Dy6wepRO/DPpwDbXSHxNEwuYGYCg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=kDlFQK8/pUTpXn1rCKCeCMTNksvb+uL7W113UICr1vnXzOPnnuf1pCeiz9uYe+IdwW FlfPTLGRCCn7ApCB1BatxrIi0Phi1C/EPUbtIKGwA7l9FQY/JiYyKLYwKW8XvF2JH5u/ PNOSwdnejmj1Ao8Z+PqKNwhXura4DUU5O215A= Original-Received: by 10.224.45.84 with SMTP id d20mr5366131qaf.210.1292344762620; Tue, 14 Dec 2010 08:39:22 -0800 (PST) Original-Received: by 10.220.203.139 with HTTP; Tue, 14 Dec 2010 08:39:22 -0800 (PST) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:8314 Archived-At: --0015175cdefa80db5f0497617641 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I've just verified that the implementations of unquote and unquote-splicing in Guile do not conform to R6RS. Perhaps this is intentional, but it would be a shame because the change in R6RS is certainly one for the better. Scheme's quasiquotation is defined very well (it's even used as a reference in Common Lisp's backquote definition) but ... it did have a major drawback= . unquote (and unquote-splicing as well) cannot be applied to multiple expressions. This messes things up a little, especially when you're dealing with nested quasiquotations. Anyway, you can't do things like this (like yo= u can in CL and R6RS): (let ((name 'foo)) `((unquote name name name))) =3D> (foo foo foo) But the latter example is nothing. You can get around it in a second. There are however MUCH worse-case scenarios which, quite possibly, cannot be worked around (or at most with ugly solutions). The current rules for evaluation are (from R6RS): If an (unquote ...) form appears inside a , however, the s are evaluated (=E2=80=9Cunquoted=E2=80=9D) and t= heir results are inserted into the structure instead of the unquote form. If an (unquote-splicing ...) form appears inside a , then the s must evaluate to lists; the opening and closing parentheses of the lists are then =E2=80=9Cstripped away=E2=80=9D a= nd the elements of the lists are inserted in place of the unquote-splicing form. Any unquote-splicing or multi-operand unquote form must appear only within = a list or vector . That just about says it all. Alan Bawden discussed the previous flaw in Scheme. Now it's cured. Hope to see the new rules in Guile too. --=20 Rocco Rossi E-Mail: rocco.rossi@gmail.com Profilo: http://www.google.com/profiles/rocco.rossi "Sono nato senza conoscere nulla e ho avuto un po' di tempo per cambiare qu= a e l=C3=A0 questa mia condizione." (Richard P. Feynman) --0015175cdefa80db5f0497617641 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I've just verified that the implementations of unquote and unquote-spli= cing in Guile do not conform to R6RS. Perhaps this is intentional, but it w= ould be a shame because the change in R6RS is certainly one for the better.= Scheme's quasiquotation is defined very well (it's even used as a = reference in Common Lisp's backquote definition) but ... it did have a = major drawback.

unquote (and unquote-splicing as well) cannot be applied to = multiple expressions. This messes things up a little, especially when you&#= 39;re dealing with nested quasiquotations. Anyway, you can't do things = like this (like you can in CL and R6RS):

(let=C2=A0((name 'foo))
=C2=A0=C2=A0`(= (unquote=C2=A0name=C2=A0name=C2=A0name)))
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D> (foo= =C2=A0foo=C2=A0foo)

But the = latter example is nothing. You can get around it in a second. There are how= ever MUCH worse-case scenarios which, quite possibly, cannot be worked arou= nd (or at most with ugly solutions).
The current rules for evaluation are (from R6RS):

=
<= p style=3D"font-family: 'Times New Roman'; font-size: medium; ">If = an=C2=A0(unquote <expression>=C2=A0...)=C2=A0form a= ppears inside a <qq template>, however, the <expression>s are e= valuated (=E2=80=9Cunquoted=E2=80=9D) and their results are inserted into t= he structure instead of the=C2=A0unquote=C2=A0form.

If= an=C2=A0(unquote-splicing <expression>=C2=A0...)= =C2=A0form appears inside a <qq template>, then the <expression>= ;s must evaluate to lists; the opening and closing parentheses of the lists= are then =E2=80=9Cstripped away=E2=80=9D and the elements of the lists are= inserted in place of the=C2=A0unquote-splicing=C2=A0form.

An= y=C2=A0unquote-splicing=C2=A0or multi-operand=C2=A0unquote=C2=A0form must appear only within a list or vector <qq template>.

That just about says it all. Alan Bawden discussed the previous flaw i= n Scheme. Now it's cured. Hope to see the new rules in Guile too.


--
Rocco Rossi

E-Mail: rocco.rossi@gmail.com
Profilo: http://www.google.com/profi= les/rocco.rossi

"Sono nato senza conoscere nulla e ho avuto un po' di tempo pe= r cambiare qua e l=C3=A0 questa mia condizione." (Richard P. Feynman)<= br>
--0015175cdefa80db5f0497617641--