From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Mikael Djurfeldt Newsgroups: gmane.lisp.guile.devel Subject: Re: goops and memoization Date: Tue, 03 Dec 2002 08:59:48 +0100 Sender: guile-devel-admin@gnu.org Message-ID: References: <02120219132603.12810@locke.free-expression.org> Reply-To: djurfeldt@nada.kth.se NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1038902533 21144 80.91.224.249 (3 Dec 2002 08:02:13 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 3 Dec 2002 08:02:13 +0000 (UTC) Cc: djurfeldt@nada.kth.se, Dirk Herrmann , Neil Jerram , 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 18J80Q-0005Ua-01 for ; Tue, 03 Dec 2002 09:02:11 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18J82G-0005jj-00; Tue, 03 Dec 2002 03:04:04 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18J81S-0005AZ-00 for guile-devel@gnu.org; Tue, 03 Dec 2002 03:03:14 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18J81Q-0005AL-00 for guile-devel@gnu.org; Tue, 03 Dec 2002 03:03:14 -0500 Original-Received: from kvast.blakulla.net ([213.212.20.77]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18J81Q-0005AH-00 for guile-devel@gnu.org; Tue, 03 Dec 2002 03:03:12 -0500 Original-Received: from barbara.blakulla.net ([213.212.21.238] helo=linnaeus) by kvast.blakulla.net with esmtp (Exim 3.36 #1 (Debian)) id 18J7yD-0003Mi-00; Tue, 03 Dec 2002 08:59:53 +0100 Original-Received: from mdj by linnaeus with local (Exim 3.36 #1 (Debian)) id 18J7y8-0007eM-00; Tue, 03 Dec 2002 08:59:48 +0100 Original-To: Lynn Winebarger Original-Cc: djurfeldt@nada.kth.se In-Reply-To: <02120219132603.12810@locke.free-expression.org> (Lynn Winebarger's message of "Mon, 2 Dec 2002 19:13:26 -0500") User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-pc-linux-gnu) 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:1777 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1777 Lynn Winebarger writes: > On Monday 02 December 2002 03:45, Mikael Djurfeldt wrote: >> procedure-source. I actually think working on the memoized >> representation is more of a hack, but that might be motivated anyway >> for reasons of efficiency. > > The problem with "unmemoizing" is that you don't have any > guarantee that 'lambda is bound to the constant system lambda > macro when you unmemoize. The real justification for memoizing > is that you're evaluating the variables 'lambda,'if,etc to system > constants. Well, actually we have a guarantee that when we re-memoize, 'lambda, 'if etc are bound to exactly the same thing as when the procedure was originally memoized. This is because the lexical environment of the method is used when re-memoizing. Note that for method optimization to work, unmemoization *must* be faithful to the semantics of the procedure. The optimizer must be able to lookup the true binding of every identifier. Thus, we have the requirement that memoization is semantically 100% reversible. Then one might of course argue that that is a too strict requirement. The original reason for the choice to work on Scheme code instead of on the memoized representation was that it was simpler and could be handled on the Scheme level, and could be made to work quickly. Then it happens that it is cleaner and more modular since the procedure-source interface separates goops code from the particular details of the current evaluator. (True with regard to this question. However, the code unfortunately contains dependencies on the evaluator's representation of the environment. *That* is a hack.) But, as said earlier, being a efficiency freak, I'd like a solution which works on the memoized code. In order to maintain a reasonably clean separation of goops code and the details of memoizing, it might then be a good idea to provide some kind of code traverser which goops can plug into and operate with minimal knowledge of memoized representation and environment. Best regards, Mikael _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel