From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Dirk Herrmann Newsgroups: gmane.lisp.guile.user Subject: Re: macros, procedure->macro Date: Wed, 10 Jul 2002 07:46:22 +0200 (CEST) Sender: guile-user-admin@gnu.org Message-ID: References: NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: main.gmane.org 1026280018 3726 127.0.0.1 (10 Jul 2002 05:46:58 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 10 Jul 2002 05:46:58 +0000 (UTC) Cc: guile-devel@gnu.org, guile-user@gnu.org Return-path: Original-Received: from fencepost.gnu.org ([199.232.76.164]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17SAJV-0000xz-00 for ; Wed, 10 Jul 2002 07:46:57 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17SAJg-0000ER-00; Wed, 10 Jul 2002 01:47:08 -0400 Original-Received: from sallust.ida.ing.tu-bs.de ([134.169.132.52]) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17SAIy-0000E1-00; Wed, 10 Jul 2002 01:46:24 -0400 Original-Received: from localhost (dirk@localhost) by sallust.ida.ing.tu-bs.de (8.9.3+Sun/8.9.1) with ESMTP id HAA15436; Wed, 10 Jul 2002 07:46:22 +0200 (CEST) Original-To: Neil Jerram In-Reply-To: Errors-To: guile-user-admin@gnu.org X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.lisp.guile.user:727 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.user:727 On 9 Jul 2002, Neil Jerram wrote: > Dirk> If all results are positive, I will go ahead and remove the support > Dirk> for "macros" from guile. After that, I will take a close look at "acros" > Dirk> and we will play a similar game with "acros" again... > > Before doing this, I think we need to state clearly when macro > expansion will happen in the future Guile. [...] > (As far as I understand, the options are just after reading and just > before memoization, but just-after-reading makes recursive macro > definitions difficult, and just-before-memoization leads to rather > lame execution-dependent expansion. Hmmm, I don't quite understand you here - to me it seems that the big difference is whether macro-expansion happens during execution, or before execution. If macro-expansion happens before execution, you could basically have one big step "macro expansion + memoization/compilation" which should cover both the just-after-reading and the just-before-memoization options. Sure, this big step is better separated into different tasks, but that can be decided later. Currently my focus is on separating the big step from execution. > Obviously, by definition, the exact timing only matters for > non-hygienic macros; but my assumption is that an awful lot of people > want non-hygienic macros.) Could you give some examples for situations where the exact timing is important? Best regards, Dirk Herrmann _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user