From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: taylanbayirli@gmail.com (Taylan Ulrich B.) Newsgroups: gmane.lisp.guile.user Subject: Re: Syntax-rules generate symbol Date: Mon, 09 Sep 2013 22:03:43 +0200 Message-ID: <871u4xdaow.fsf@taylan.uni.cx> References: <87txhuarxf.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1378757051 638 80.91.229.3 (9 Sep 2013 20:04:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 9 Sep 2013 20:04:11 +0000 (UTC) Cc: "guile-user@gnu.org" , Dmitry Bogatov To: Panicz Maciej Godek Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Mon Sep 09 22:04:15 2013 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VJ7h0-0006uI-Vc for guile-user@m.gmane.org; Mon, 09 Sep 2013 22:04:15 +0200 Original-Received: from localhost ([::1]:53514 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VJ7h0-0001N4-7e for guile-user@m.gmane.org; Mon, 09 Sep 2013 16:04:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40544) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VJ7gi-0001MV-1K for guile-user@gnu.org; Mon, 09 Sep 2013 16:04:00 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VJ7ga-0003Sq-Rd for guile-user@gnu.org; Mon, 09 Sep 2013 16:03:55 -0400 Original-Received: from mail-ee0-x22b.google.com ([2a00:1450:4013:c00::22b]:51574) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VJ7ga-0003SZ-Ka; Mon, 09 Sep 2013 16:03:48 -0400 Original-Received: by mail-ee0-f43.google.com with SMTP id e52so3410872eek.16 for ; Mon, 09 Sep 2013 13:03:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=Piugq4T5L9ahbkfcgMgP4U9CMZMGSwzY486ExJwPAqU=; b=MVIGFSiuAjJag5uDfBieF5bvKuYT/A9ilkmPHJisNEa3ckMPvVAGFz02q7Yr3H1Qx1 uf3sLqyxJZiobGGqlaS5f3f740KPNjjrh3eHOiIFwXC3xX9kZHlIr24q1DwDuBKkLG5s 6mWUHHwqm/IWlYefub1MeHkYLRmfB59wMQun2J10Fa9Z0ANFPgJPNJCW3aqCkznL6jep nyTwPVyyaNXB5DPSaE75j+h7NW8XmgQdx6Fw4WKSH4Sc7HRBBr5RQsyYjf3Hx8pDGsKe KNgxbO5xDw8g6uwMtbTcEHMuwIzJ3cuJjZBV9qyQBQh0ENH5Bjx/mzNyob2TIKhJSkfF N1xQ== X-Received: by 10.15.32.136 with SMTP id a8mr20192eev.71.1378757026841; Mon, 09 Sep 2013 13:03:46 -0700 (PDT) Original-Received: from taylan.uni.cx (p4FD91846.dip0.t-ipconnect.de. [79.217.24.70]) by mx.google.com with ESMTPSA id x47sm24670487eea.16.1969.12.31.16.00.00 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 09 Sep 2013 13:03:46 -0700 (PDT) In-Reply-To: (Panicz Maciej Godek's message of "Mon, 9 Sep 2013 18:59:06 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4013:c00::22b X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:10775 Archived-At: Panicz Maciej Godek writes: > Actually, the whole point of hygienic (syntax-rules) macros > is that you don't need to worry about the names of variables. > > I often use a very similar python-like for loop macro in my projects: > > http://hg.gnu.org.ua/hgweb/slayer/file/554a63bd3c6c/guile-modules/extra/common. > scm#l420 > > That code works just perfectly fine. > > IMO a bigger problem would be to break the referential > transparency, so e.g. the definition like > > (define-syntax for > (syntax-rules (in => break) > ((_ pattern in list body ...) > (call/cc (lambda(break) > (for-each (match-lambda pattern body ...) list)))))) > > won't work as one might expect (i.e. you won't be able to write > (break) inside a loop, because the "break" label gets renamed). > The workaround is possible somehow, but I never had time to > figure that out, so currently I just don't do breaks ;] > > Best regards, > M. For anyone who didn't know, "breaking" to arbitrary places is made simple (and efficient) with `let/ec' from the module (ice-9 control), a wrapper around `call-with-escape-continuation': (let/ec break (display "foo\n") (break) (display "bar\n")) displays only foo. One can return any number of values of course: (let-values (((foo bar baz) (let/ec return (display "what should I return?\n") (return 1 2 3)))) (+ foo bar baz)) ;=> 6 (`let-values' is in SRFI 11.) An "escape" continuation cannot be "re-entered" after it returns once, making the following usage invalid, but thus the implementation very efficient: (let ((re-enter #f)) (display (let/ec display-this (set! re-enter display-this) (display-this "foo\n))) (re-enter "infinite foos!\n")) If we used call/cc, that would loop infinitely displaying "infinite foos!" (after the first "foo"), but with the escape continuation we just get an error after displaying the first "foo", because once we return from the escape continuation we can't call it anymore even if we store it somewhere.