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: Re: macros, procedure->macro Date: Wed, 3 Jul 2002 22:11:56 +0200 (CEST) Sender: guile-devel-admin@gnu.org Message-ID: References: <87adpbxfio.fsf@zagadka.ping.de> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: main.gmane.org 1025727104 16919 127.0.0.1 (3 Jul 2002 20:11:44 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 3 Jul 2002 20:11:44 +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 17PqTY-0004Om-00 for ; Wed, 03 Jul 2002 22:11:44 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 17PqTq-0001Xx-00; Wed, 03 Jul 2002 16:12:02 -0400 Original-Received: from sallust.ida.ing.tu-bs.de ([134.169.132.52]) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 17PqTn-0001Wz-00; Wed, 03 Jul 2002 16:11:59 -0400 Original-Received: from localhost (dirk@localhost) by sallust.ida.ing.tu-bs.de (8.9.3+Sun/8.9.1) with ESMTP id WAA27838; Wed, 3 Jul 2002 22:11:56 +0200 (CEST) Original-To: Marius Vollmer In-Reply-To: <87adpbxfio.fsf@zagadka.ping.de> 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:739 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:739 On 2 Jul 2002, Marius Vollmer wrote: > Dirk Herrmann writes: > > > 1) Some macro expert should check that replacing the call to > > procedure->macro in boot-9.scm by a call to procedure->memoizing-macro is > > safe. > > Err, I'm no macro expert, but I fully agree that "acros" and "macros" > should be removed. So even if it would not be OK to just replace the > use of procedure->macro with procedure->memoizing-macro, we need to > find a solution that doesn't use the former. OK, lets assume we want to get rid of "acros" and "macros". When should that happen, and when should the corresponding functions be removed from guile? 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. Hmm? Best regards Dirk _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel