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:19:21 +0100 Sender: guile-devel-admin@gnu.org Message-ID: References: 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 1038968353 5528 80.91.224.249 (4 Dec 2002 02:19:13 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 4 Dec 2002 02:19:13 +0000 (UTC) Cc: djurfeldt@nada.kth.se, 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 18JP83-0001Qx-00 for ; Wed, 04 Dec 2002 03:19: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 18JP8u-0004Un-00; Tue, 03 Dec 2002 21:20:04 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18JP8b-000460-00 for guile-devel@gnu.org; Tue, 03 Dec 2002 21:19:45 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18JP8Z-00044p-00 for guile-devel@gnu.org; Tue, 03 Dec 2002 21:19:45 -0500 Original-Received: from kvast.blakulla.net ([213.212.20.77]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18JP8Z-00043U-00 for guile-devel@gnu.org; Tue, 03 Dec 2002 21:19:43 -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 18JP8J-00039Q-00; Wed, 04 Dec 2002 03:19:27 +0100 Original-Received: from mdj by linnaeus with local (Exim 3.36 #1 (Debian)) id 18JP8H-0002Y3-00; Wed, 04 Dec 2002 03:19:25 +0100 Original-To: Dirk Herrmann Original-Cc: djurfeldt@nada.kth.se In-Reply-To: (Dirk Herrmann's message of "Tue, 3 Dec 2002 22:39:01 +0100 (CET)") 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:1783 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1783 Dirk Herrmann writes: > As stated in my previous mail the output of procedure-source is not the > full scheme code that is necessary to re-memoize the code: > guile> (define foo (let ((bar 1)) (lambda () bar))) > guile> (procedure-source foo) > --> (lambda () bar) > That is, trying to re-translate this output is not as clean a separation > as you claim. You depend on the fact that during execution there is > sufficient information available to reliably re-compile any code such that > it fits into the rest of the compiled code around it. That is a strong > assumption and it may prove to be expensive to guarantee it. Could you explain this to me? Why is it such a strong assumption? My obvious counter example is: (define foo2 (local-eval (procedure-source foo) (procedure-environment foo))) (foo2) --> 1 [There is a need here to treat the first `lambda' specially, but that is a trivial problem.] Which do you think puts the heavier constraint, procedure-source or procedure-environment? Note that there is no assumption needed that procedure-source returns the verbatim source expression from which the closure was created. And an environment is simply a mapping of variables to bindings. Note that there is nothing "around" the method into which it should fit. The method has it's own closed environment. > I had not actually planned to work on goops itself, and I will try > to avoid doing so if possible - my resources are limited. If we can > agree on one way to go, I would prefer if I would not have to modify > goops myself. That is fine. Can you share your current source? > To get around the current problems (which are only relevant in my private > copy of guile - none of my changes are yet submitted) I have suggested to > replace one kind of dependency between goops and the evaluator > (compile-method relying on the possibility to re-compile the output of > procedure-source) by another one (compile-method working directly on the > memoized code). You are suggesting a different way, namely to add an > interface to allow memoization of re-compiled scheme code and re-insert > this code into the rest of the memoized code, which is just another form > of dependency. My preferred long-term solution, to have optimization > functions work on a post-syntax-expansion-pre-memoization intermediate > format also gets rid of some dependencies and adds a dependency on the > intermediate format. Dependencies are acceptable if they are between > parts of the code which are stable, which I hope the future and yet to be > defined intermediate format to be. Well, I may be dense, but * You have still failed to show to me why the second alternative (working on Scheme source) introduces any kind of dependencies (given that we fix the "hole"). I'd really want you to try to convince me about that. * I like your suggestion for long-term solution. And, * It's perfectly fine with me to re-implement compile-method in C, working on the memoized representation. Best regards, Mikael _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel