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: Wed, 04 Dec 2002 03:41:27 +0100 Sender: guile-devel-admin@gnu.org Message-ID: References: <02120219132603.12810@locke.free-expression.org> <02120312173604.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 1038973322 24777 80.91.224.249 (4 Dec 2002 03:42:02 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 4 Dec 2002 03:42:02 +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 18JQQA-0006R1-00 for ; Wed, 04 Dec 2002 04:41:58 +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 18JQPI-00083y-00; Tue, 03 Dec 2002 22:41:04 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18JQOZ-0007q1-00 for guile-devel@gnu.org; Tue, 03 Dec 2002 22:40:19 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18JQOT-0007oP-00 for guile-devel@gnu.org; Tue, 03 Dec 2002 22:40:17 -0500 Original-Received: from gnudist.gnu.org ([199.232.41.7]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18JQOT-0007mM-01 for guile-devel@gnu.org; Tue, 03 Dec 2002 22:40:13 -0500 Original-Received: from kvast.blakulla.net ([213.212.20.77]) by gnudist.gnu.org with esmtp (Exim 4.10.13) id 18JPTg-00069i-00 for guile-devel@gnu.org; Tue, 03 Dec 2002 21:41:32 -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 18JPTb-0003BW-00; Wed, 04 Dec 2002 03:41:27 +0100 Original-Received: from mdj by linnaeus with local (Exim 3.36 #1 (Debian)) id 18JPTb-0002bP-00; Wed, 04 Dec 2002 03:41:27 +0100 Original-To: Lynn Winebarger Original-Cc: djurfeldt@nada.kth.se In-Reply-To: <02120312173604.12810@locke.free-expression.org> (Lynn Winebarger's message of "Tue, 3 Dec 2002 12:17:36 -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:1793 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1793 Lynn Winebarger writes: > On Tuesday 03 December 2002 02:59, Mikael Djurfeldt wrote: >> 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. > > Either define-syntax or define can change the meaning of > lambda in the global environment. It will use the same binding, > true, but that's not the same thing. Since procedure-source operates on a closure, I already know for sure what kind of "lambda" created it. As for other mentions of lambda, procedure-environment will tell me what they mean. > The memoizer is not an optimizer. It merely expands macros > into a constant core representation. I fail to understand the > problem. Problem 1: The optimizer gets dependent upon the memoized representation. [The goops dependencies that Dirk mention are really minor (except for the current lack of an abstraction barrier towards the environment) and can be adjusted quickly if things changes.] Problem 2: Working on the memoized representation prevents writing optimizations in Scheme. >> Thus, we have the requirement that memoization is semantically 100% >> reversible. Then one might of course argue that that is a too strict >> requirement. > > Requiring reversibility of arbitrary macro expansions is pretty > close to nuts. Reversibility of macro expansions is not required. The optimizer in fact works better if all macros already are expanded. >> 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. > > If you do it at the scheme level, sure. But if you're doing it at the > C level you have to use some system-specific representation anyway. > So what's wrong with constants? Nothing except for problems 1 and 2 above. (Clarification regarding problem 1: The "system-specific representation" you talk about is not likely to change and trivial to modify if a change should occur while large parts of the optimizer might need to be rewritten if the memoized representation changes. Consider, for example, that the tree structure of IM_DO is different from that of "do" and it's quite easy to imagine quite a lot stranger representations.) Best regards, Mikael _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel