From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andy Wingo Newsgroups: gmane.lisp.guile.bugs Subject: bug#10099: Null (begin) blocks - V2.0.3 reports error was OK in V2.0.2 Date: Wed, 21 Dec 2011 20:17:47 -0500 Message-ID: <8762h9s8uc.fsf@pobox.com> References: <4ECA89A5.5090202@hulin.org.uk> <871usznhvv.fsf@pobox.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1324516691 18707 80.91.229.12 (22 Dec 2011 01:18:11 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 22 Dec 2011 01:18:11 +0000 (UTC) Cc: 10099-done@debbugs.gnu.org, Ludovic =?UTF-8?Q?Court=C3=A8s?= , Han-Wen Nienhuys To: Ian Hulin Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Thu Dec 22 02:18:04 2011 Return-path: Envelope-to: guile-bugs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RdXIH-0004JN-H4 for guile-bugs@m.gmane.org; Thu, 22 Dec 2011 02:18:01 +0100 Original-Received: from localhost ([::1]:40482 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RdXIH-0005BZ-04 for guile-bugs@m.gmane.org; Wed, 21 Dec 2011 20:18:01 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:47597) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RdXID-0005BE-Dv for bug-guile@gnu.org; Wed, 21 Dec 2011 20:17:58 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RdXIB-0007eq-RL for bug-guile@gnu.org; Wed, 21 Dec 2011 20:17:57 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:47664) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RdXIB-0007ej-OF for bug-guile@gnu.org; Wed, 21 Dec 2011 20:17:55 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1RdXKE-0007Ve-DZ for bug-guile@gnu.org; Wed, 21 Dec 2011 20:20:02 -0500 Resent-From: Andy Wingo Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: bug-guile@gnu.org Resent-Date: Thu, 22 Dec 2011 01:20:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: cc-closed 10099 X-GNU-PR-Package: guile X-GNU-PR-Keywords: Mail-Followup-To: 10099@debbugs.gnu.org, wingo@pobox.com Original-Received: via spool by 10099-done@debbugs.gnu.org id=D10099.132451680028854 (code D ref 10099); Thu, 22 Dec 2011 01:20:02 +0000 Original-Received: (at 10099-done) by debbugs.gnu.org; 22 Dec 2011 01:20:00 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RdXKC-0007VL-KL for submit@debbugs.gnu.org; Wed, 21 Dec 2011 20:20:00 -0500 Original-Received: from a-pb-sasl-sd.pobox.com ([74.115.168.62] helo=sasl.smtp.pobox.com) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RdXKA-0007VD-0d for 10099-done@debbugs.gnu.org; Wed, 21 Dec 2011 20:19:59 -0500 Original-Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 9E19F88BD; Wed, 21 Dec 2011 20:17:50 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=sasl; bh=2+WHAEfPGhXM5+fX8MakABNie5U=; b=O4VWmh ffwL1TnO+ttnjnGQEKXh1x46U2qPR9E4vbPhsHU5yDC41wBJ/TlOvVQuSVp+ivRD c8yS9G+sNoGMXB1wDsUJT8GiFeG6xKaqI21cvP/+EHCYwBsjozcLgsBfKzQ2AqDL UuGx5e2lDt0eIG/O8bXXFZd9cWeK/WvJZA+Sg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; q=dns; s=sasl; b=nn+0cLnRpnu426CmtHNGc4yZzmcYf41U wrgyHi/h20pZ5jI1KLyatuGn8/b/co8YkCh1Srq2qLfr5V+FGz+8acC9u+EcBCBO bwpC4kMgomJP4vd42Gg3LvpbmixUDAlcKQ54EJVbSAofGdEkJLjcuqNvqe7Dwt/N rWPDKdwaD/U= Original-Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 966C688BC; Wed, 21 Dec 2011 20:17:50 -0500 (EST) Original-Received: from badger (unknown [184.174.165.119]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 398A088BB; Wed, 21 Dec 2011 20:17:50 -0500 (EST) In-Reply-To: <871usznhvv.fsf@pobox.com> (Andy Wingo's message of "Wed, 23 Nov 2011 13:27:32 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) X-Pobox-Relay-ID: C3CF687E-2C3A-11E1-8ED7-65B1DE995924-02397024!a-pb-sasl-sd.pobox.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Wed, 21 Dec 2011 20:20:02 -0500 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-guile@gnu.org List-Id: "Bug reports for GUILE, GNU's Ubiquitous Extension Language" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Original-Sender: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.bugs:6002 Archived-At: Hi, On Wed 23 Nov 2011 07:27, Andy Wingo writes: > On Tue 22 Nov 2011 00:02, Andy Wingo writes: >>On Mon 21 Nov 2011 18:25, Ian Hulin writes: >>> (define-public (void? x) (eq? x (begin))) >>> This works in V1.8, and apparently used to work in 2.0.2 (no errors), >> >> Interesting. If it changed incompatibly in 2.0.x, that is a Guile bug. >> Sorry about that! We'll fix it. > > I cannot reproduce this issue with 2.0.2. I suspect that this code has > been this way since early 1.9 releases, and is a consquence of switching > to the new syntax expander. > > That said, this change was not mentioned in NEWS, and the documentation > has not been updated, so perhaps we should do something. I would prefer > just to leave it as it is, unless you think that adding a compatibility > hack could help you somehow. What do you think, Ian? I have appended the updated documentation to this reply to clarify that (begin) in expression context is invalid syntax. I have also added a backwards-compatibility shim to issue a deprecation warning and translate it to *unspecified*, in Guile 2.0. That should fix this bug. Regards, Andy 6.13.1 Sequencing and Splicing ------------------------------ As an expression, the `begin' syntax is used to evaluate a sequence of sub-expressions in order. Consider the conditional expression below: (if (> x 0) (begin (display "greater") (newline))) If the test is true, we want to display "greater" to the current output port, then display a newline. We use `begin' to form a compound expression out of this sequence of sub-expressions. -- syntax: begin expr1 expr2 ... The expression(s) are evaluated in left-to-right order and the value of the last expression is returned as the value of the `begin'-expression. This expression type is used when the expressions before the last one are evaluated for their side effects. The `begin' syntax has another role in definition context (*note Internal Definitions::). A `begin' form in a definition context "splices" its subforms into its place. For example, consider the following procedure: (define (make-seal) (define-sealant seal open) (values seal open)) Let us assume the existence of a `define-sealant' macro that expands out to some definitions wrapped in a `begin', like so: (define (make-seal) (begin (define seal-tag (list 'seal)) (define (seal x) (cons seal-tag x)) (define (sealed? x) (and (pair? x) (eq? (car x) seal-tag))) (define (open x) (if (sealed? x) (cdr x) (error "Expected a sealed value:" x)))) (values seal open)) Here, because the `begin' is in definition context, its subforms are "spliced" into the place of the `begin'. This allows the definitions created by the macro to be visible to the following expression, the `values' form. It is a fine point, but splicing and sequencing are different. It can make sense to splice zero forms, because it can make sense to have zero internal definitions before the expressions in a procedure or lexical binding form. However it does not make sense to have a sequence of zero expressions, because in that case it would not be clear what the value of the sequence would be, because in a sequence of zero expressions, there can be no last value. Sequencing zero expressions is an error. It would be more elegant in some ways to eliminate splicing from the Scheme language, and without macros (*note Macros::), that would be a good idea. But it is useful to be able to write macros that expand out to multiple definitions, as in `define-sealant' above, so Scheme abuses the `begin' form for these two tasks. -- http://wingolog.org/