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: bug in syncase Date: Sat, 23 Nov 2002 11:53:54 +0100 (CET) Sender: guile-devel-admin@gnu.org Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: main.gmane.org 1038049450 8301 80.91.224.249 (23 Nov 2002 11:04:10 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sat, 23 Nov 2002 11:04:10 +0000 (UTC) Cc: Guile Development Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18FY53-00029i-00 for ; Sat, 23 Nov 2002 12:04:09 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 18FXvK-0006AG-00; Sat, 23 Nov 2002 05:54:06 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 18FXvD-0006A4-00 for guile-devel@gnu.org; Sat, 23 Nov 2002 05:53:59 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 18FXvB-00069t-00 for guile-devel@gnu.org; Sat, 23 Nov 2002 05:53:58 -0500 Original-Received: from sallust.ida.ing.tu-bs.de ([134.169.132.52]) by monty-python.gnu.org with esmtp (Exim 4.10) id 18FXvA-00069p-00 for guile-devel@gnu.org; Sat, 23 Nov 2002 05:53:57 -0500 Original-Received: from localhost (dirk@localhost) by sallust.ida.ing.tu-bs.de (8.9.3+Sun/8.9.1) with ESMTP id LAA25858; Sat, 23 Nov 2002 11:53:54 +0100 (CET) Original-To: Neil Jerram In-Reply-To: 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:1743 On 21 Nov 2002, Neil Jerram wrote: > >>>>> "Dirk" == Dirk Herrmann writes: > > Dirk> In the current implementation, the decision, how the @fop > Dirk> expression should be changed, would be taken when foo was > Dirk> set to 2. In contrast, with my memoization phase I would > Dirk> like to perform the transformation (including the expansion > Dirk> of the transformer-macro expression) at the point where bar > Dirk> gets defined. > > Dirk> In other words: Are there any statements about _when_ the > Dirk> expansion of the @fop macro and the transformer-macro should > Dirk> happen? > > I would say that there are no statements except that transformed Elisp > code should behave in the same way as Emacs. > > In Emacs: [example deleted] > > In Guile (current unstable CVS): [example deleted] > > So Guile as it stands is already wrong in the last result. It looks > as though Emacs behaves as though there is no memoization at all. There is a mechanism in scheme that allows to prevent memoization: eval. If it is correct that emacs does not perform memoization, then it might be that the whole concept of the @fop memoization is wrong. Could you check whether it is possible to achieve emacs' behaviour by replacing the @fop solution by a solution based on eval (or some elisp equivalent of this)? I would postpone working on @fop until this is solved - there are still enough other things to do for me :-) Best regards Dirk _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel