From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Neil Jerram Newsgroups: gmane.lisp.guile.devel Subject: Re: goops and memoization Date: 29 Nov 2002 22:48:47 +0000 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 1038610654 30642 80.91.224.249 (29 Nov 2002 22:57:34 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Fri, 29 Nov 2002 22:57:34 +0000 (UTC) Cc: djurfeldt@nada.kth.se, guile-devel@gnu.org 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 18Hu4i-0007xw-00 for ; Fri, 29 Nov 2002 23:57:32 +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 18Hu6F-00017V-00; Fri, 29 Nov 2002 17:59:07 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 18Hu2o-0007ut-00 for guile-devel@gnu.org; Fri, 29 Nov 2002 17:55:34 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 18Hu2m-0007uC-00 for guile-devel@gnu.org; Fri, 29 Nov 2002 17:55:33 -0500 Original-Received: from mail.uklinux.net ([80.84.72.21] helo=s1.uklinux.net) by monty-python.gnu.org with esmtp (Exim 4.10) id 18Hu2l-0007tp-00 for guile-devel@gnu.org; Fri, 29 Nov 2002 17:55:32 -0500 Original-Received: from laruns.ossau.uklinux.net (bts-0729.dialup.zetnet.co.uk [194.247.50.217]) by s1.uklinux.net (8.11.6/8.11.6) with ESMTP id gATMtSk18751; Fri, 29 Nov 2002 22:55:28 GMT Original-Received: from laruns.ossau.uklinux.net.ossau.uklinux.net (localhost [127.0.0.1]) by laruns.ossau.uklinux.net (Postfix on SuSE Linux 7.2 (i386)) with ESMTP id B6928DC12B; Fri, 29 Nov 2002 22:48:48 +0000 (GMT) Original-To: Dirk Herrmann In-Reply-To: Original-Lines: 62 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 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:1763 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1763 >>>>> "Mikael" == Mikael Djurfeldt writes: Mikael> Dirk Herrmann writes: >> This conflicts with goops: goops unmemoizes the function code, using >> 'procedure-source' (look into oop/goops/compile.scm). This will re-create >> the original code, including all the symbols that refer to local >> variables. This un-memoized code is then optimized in some way, and >> re-written into the closure object. Then, if the closure is evaluated, it >> is not run through the memoizer again (since it is already a closure). Mikael> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Mikael> Just a note: This is something which holds *after* your Mikael> change, not previously. [...] Mikael> It seems to me that what you need to do is to run the tail of the Mikael> cmethod (BODY-FORM1 ...) through your memoizer. That should fix it. Indeed. If I understand correctly, what happens is that scm_memoize_method in eval.c returns an unevaluated and unmemoized lambda form, which the current evaluator handles by calling scm_m_lambda, which performs the memoization stage. The problem I presume is that your optimized evaluator doesn't handle symbols in the CAR, because it shouldn't need to. If this is correct, the fix is to pass `x' through your memoizer just before `goto nontoplevel_begin;', like this: apply_cmethod: /* inputs: z, arg1 */ { SCM formals = SCM_CMETHOD_FORMALS (z); env = EXTEND_ENV (formals, arg1, SCM_CMETHOD_ENV (z)); x = SCM_CMETHOD_BODY (z); x = memoize (x); /* ADDED */ goto nontoplevel_begin; } A few notes: - You could just call eval instead of memoizing and goto nontoplevel_begin, but that wouldn't be tail-recursive. I wonder if tail recursion is important here? - Is the memoization stage sufficient here? What if the method definition came from a module with a syntax transformer in effect? If `procedure-source' returns post-transformation code, all is OK. If it doesn't, there are two possible problems: - The code returned by scm_memoize_method should be retransformed as well as rememoized. - `compile-method's manipulation of the source code might not work in the pre-transformation language. - Quite a few places in the GOOPS code use local-eval. Does local-eval still include memoization (and syntax transformation?) in your codebase? I hope this helps; let me know if you would like me to dig or experiment further. Neil _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel