From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Dirk Herrmann Newsgroups: gmane.lisp.guile.devel Subject: Internal defines Date: Sun, 09 Nov 2003 23:40:26 +0100 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: <3FAEC259.302@dirk-herrmanns-seiten.de> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1068416583 23478 80.91.224.253 (9 Nov 2003 22:23:03 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 9 Nov 2003 22:23:03 +0000 (UTC) Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Nov 09 23:23:01 2003 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AIxxV-0001VS-00 for ; Sun, 09 Nov 2003 23:23:01 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AIyum-0004zh-B6 for guile-devel@m.gmane.org; Sun, 09 Nov 2003 18:24:16 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AIyuf-0004yD-T7 for guile-devel@gnu.org; Sun, 09 Nov 2003 18:24:09 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AIyu9-0004CD-0h for guile-devel@gnu.org; Sun, 09 Nov 2003 18:24:08 -0500 Original-Received: from [212.227.126.187] (helo=moutng.kundenserver.de) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AIyu8-00048U-DJ for guile-devel@gnu.org; Sun, 09 Nov 2003 18:23:36 -0500 Original-Received: from [212.227.126.155] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1AIxwh-0004er-00 for guile-devel@gnu.org; Sun, 09 Nov 2003 23:22:11 +0100 Original-Received: from [80.131.40.229] (helo=dirk-herrmanns-seiten.de) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1AIxwg-0001iv-00; Sun, 09 Nov 2003 23:22:11 +0100 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: de, en Original-To: Guile-Devel Mailing List , Marius Vollmer X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.2 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:2980 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:2980 Hi folks, Guile currently chokes on the following form: (defmacro a forms (cons 'define forms)) (let ((c identity) (x #t)) (define (a x y) (and x y)) (a (c x) (c x)))) According to R5RS, the body of a form like lambda, let, let* etc. looks like follows: --> * --> * --> --> (define ) | (define ( ) ) | (begin *) That is, it starts with zero or more definitions followed by one or more expressions. The definition forms must start with the literal symbol 'define' or 'begin', which may enclose further definitions or begin forms. In any case, there is no mentioning of macro expansion here. In other words, the examle code above should return #t, because the expression (a (c x) (c x)) refers to the internal define rather than to the outer macro. Guile, however, has up to now performed macro expansion before checking whether the form is a definition. Thus, the example above returns an error, since Guile interprets (a (c x) (c x)) as a macro application, in this case a definition. The body then (according to Guile's interpretation) consists only of definitions. The above example also shows that it is no good practice to define macros that expand into definitions. Messing with 'define' always means to play around with one of scheme's most basic syntactical structures. The optargs implementation of define* is an example for a macro that expands to a 'define' form. According to R5RS and as demonstrated by the above example, such macros are confusing, and Guile's current implementation breaks code that already has a meaning with respect to R5RS. I am about to submit a patch that fixes Guile's behaviour, such that the example above would work. This means, that there is not macro expansion performed prior to detecting the internal defines. I want, however, to check with you before doing so, since it is likely to break existing code. In the long term, just to mention it early, I would also like to fix Guile's code such that it also handles top-level defines correctly, since there a similar problem applies. Best regards Dirk Herrmann _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel