From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Kevin Ryde Newsgroups: gmane.lisp.guile.devel Subject: let-values, and-let* no variables Date: Fri, 20 Aug 2004 11:27:37 +1000 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: <87isbea99y.fsf@zip.com.au> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1092965298 1285 80.91.224.253 (20 Aug 2004 01:28:18 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 20 Aug 2004 01:28:18 +0000 (UTC) Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Aug 20 03:28:14 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BxyCT-0004ZR-00 for ; Fri, 20 Aug 2004 03:28:14 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BxyGl-00033p-E1 for guile-devel@m.gmane.org; Thu, 19 Aug 2004 21:32:39 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BxyGi-000335-GP for guile-devel@gnu.org; Thu, 19 Aug 2004 21:32:36 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BxyGh-00032a-0J for guile-devel@gnu.org; Thu, 19 Aug 2004 21:32:36 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BxyGf-00032X-OM for guile-devel@gnu.org; Thu, 19 Aug 2004 21:32:34 -0400 Original-Received: from [61.8.0.84] (helo=mailout1.pacific.net.au) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BxyC7-0006G7-I0 for guile-devel@gnu.org; Thu, 19 Aug 2004 21:27:52 -0400 Original-Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87]) by mailout1.pacific.net.au (8.12.3/8.12.3/Debian-6.6) with ESMTP id i7K1Rl4u031603 for ; Fri, 20 Aug 2004 11:27:47 +1000 Original-Received: from localhost (ppp2529.dyn.pacific.net.au [61.8.37.41]) by mailproxy2.pacific.net.au (8.12.3/8.12.3/Debian-6.6) with ESMTP id i7K1Rk78003604 for ; Fri, 20 Aug 2004 11:27:46 +1000 Original-Received: from gg by localhost with local (Exim 3.36 #1 (Debian)) id 1BxyBt-0003Lz-00; Fri, 20 Aug 2004 11:27:37 +1000 Original-To: guile-devel@gnu.org Mail-Copies-To: never User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (gnu/linux) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.lisp.guile.devel:3988 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:3988 I'm contemplating the way "begin" is used for the body of let-values and and-let* with no bindings. It has the unhappy effect of allowing what is visually an internal define to go out into the containing environment, eg. (use-modules (srfi srfi-11)) (let-values () (define x 123) 456) (display x) ;; prints 123 The reference implementation of srfi-11 seems pretty clear that "begin" is intended for let-values, and the formal semantics part of srfi-2 suggests the same for and-let*. Dunno if that's only an oversight regarding begin versus internal defines though. I guess nobody would write an empty and-let* or let-values deliberately, but it could arise out of a macro. I'm thinking to put some words of caution in the manual, to make it clear the body isn't the same as a plain "let" or "let*". _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel