From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Marius Vollmer Newsgroups: gmane.lisp.guile.devel Subject: Re: macros, procedure->macro Date: 09 Jul 2002 20:22:41 +0200 Sender: guile-devel-admin@gnu.org Message-ID: <87ptxwdamm.fsf@zagadka.ping.de> References: NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1026238958 27621 127.0.0.1 (9 Jul 2002 18:22:38 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 9 Jul 2002 18:22:38 +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 17RzdG-0007BN-00 for ; Tue, 09 Jul 2002 20:22:38 +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 17Rzdl-0000wQ-00; Tue, 09 Jul 2002 14:23:09 -0400 Original-Received: from dialin.speedway42.dip23.dokom.de ([195.138.42.23] helo=zagadka.ping.de) by fencepost.gnu.org with smtp (Exim 3.35 #1 (Debian)) id 17RzdN-0000tk-00 for ; Tue, 09 Jul 2002 14:22:45 -0400 Original-Received: (qmail 1468 invoked by uid 1000); 9 Jul 2002 18:22:41 -0000 Original-To: Dirk Herrmann In-Reply-To: Original-Lines: 35 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Errors-To: guile-devel-admin@gnu.org X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Developers list for Guile, the GNU extensibility library List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.lisp.guile.devel:764 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:764 Dirk Herrmann writes: > > > Removing these would change the interface. According to our > > > standard procedure, this would mean going through a phase of > > > deprecating the corresponding functions. However, this would mean, > > > we could not actually proceed with working on the evaluator, since > > > as long as those functions exist (even if deprecated) it is not > > > possible to split up the evaluator. > > > > Is it really impossible? I'd say it can be done, as long as we have > > 'local-eval'. > > Could you explain how you think it should be done? Especially how you > think one should obtain the local environment during execution. The local environment is just there during execution, isn't it? We need to keep using our current data structure for it that can be searched for local variables. We could not immediately switch to a more streamlined data structure for environments that omits these names. Actually, we need only keep the old data structure for code that uses "acros" or "macros". This can be determined at memoization time. So if we are really want to switch to a different environment representation, we can do that while still providing "acros" and "macros", but it would probably too much work. Then, when we have a 'traditional' environment, we can pass this environment to the "acro" and "macro" transformers and use it to memoize and execute the code returned by the "macro". > In any case, I think it should be a temporary solution to be able to > go through a phase of deprecation of acros and macros. Yes. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel