From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Lynn Winebarger Newsgroups: gmane.lisp.guile.devel Subject: Re: goops and memoization Date: Tue, 3 Dec 2002 12:17:36 -0500 Sender: guile-devel-admin@gnu.org Message-ID: <02120312173604.12810@locke.free-expression.org> References: <02120219132603.12810@locke.free-expression.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Trace: main.gmane.org 1038936297 11510 80.91.224.249 (3 Dec 2002 17:24:57 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 3 Dec 2002 17:24:57 +0000 (UTC) Cc: 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 18JGn0-0002zK-01 for ; Tue, 03 Dec 2002 18:24:54 +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 18JGnE-0004EK-00; Tue, 03 Dec 2002 12:25:08 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18JGmp-00046Y-00 for guile-devel@gnu.org; Tue, 03 Dec 2002 12:24:43 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18JGmn-00046M-00 for guile-devel@gnu.org; Tue, 03 Dec 2002 12:24:43 -0500 Original-Received: from plounts.uits.indiana.edu ([129.79.1.73]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18JGmn-00046I-00 for guile-devel@gnu.org; Tue, 03 Dec 2002 12:24:41 -0500 Original-Received: from logchain.uits.indiana.edu (logchain.uits.indiana.edu [129.79.1.77]) by plounts.uits.indiana.edu (8.12.1/8.12.1/IUPO) with ESMTP id gB3HOaAB028932; Tue, 3 Dec 2002 12:24:36 -0500 (EST) Original-Received: from locke.free-expression.org (dial-123-104.dial.indiana.edu [156.56.123.104]) by logchain.uits.indiana.edu (8.12.1/8.12.1/IUPO) with SMTP id gB3HOXZq020796; Tue, 3 Dec 2002 12:24:33 -0500 (EST) Original-To: djurfeldt@nada.kth.se X-Mailer: KMail [version 1.2] 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:1779 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1779 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. > 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. The memoizer is not an optimizer. It merely expands macros into a constant core representation. I fail to understand the problem. The internal constants are precisely what you want - a representation of core scheme (plus some things like "and" and "or" that are syntactic sugar but implemented for speed). They're not pointers into a run-time symbol table, but so what? It's easy to translate them to symbols for printing purposes. > 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. > 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? Lynn _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel