From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Rob Browning Newsgroups: gmane.lisp.guile.devel Subject: Re: memoization and conditional defines Date: Thu, 07 Nov 2002 21:11:17 -0600 Sender: guile-devel-admin@gnu.org Message-ID: <87vg387o2y.fsf@raven.i.defaultvalue.org> References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1036726397 12317 80.91.224.249 (8 Nov 2002 03:33:17 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Fri, 8 Nov 2002 03:33:17 +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 189ztT-0003CW-00 for ; Fri, 08 Nov 2002 04:33:15 +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 189zoB-0007sw-00; Thu, 07 Nov 2002 22:27:47 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 189zZ1-00041o-00 for guile-devel@gnu.org; Thu, 07 Nov 2002 22:12:07 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 189zYH-0002xh-00 for guile-devel@gnu.org; Thu, 07 Nov 2002 22:12:05 -0500 Original-Received: from n66644228.ipcdsl.net ([66.64.4.228] helo=defaultvalue.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 189zYG-0002th-00 for guile-devel@gnu.org; Thu, 07 Nov 2002 22:11:20 -0500 Original-Received: from raven.i.defaultvalue.org (raven.i.defaultvalue.org [192.168.1.7]) by defaultvalue.org (Postfix) with ESMTP id 566411021; Thu, 7 Nov 2002 21:11:18 -0600 (CST) Original-Received: by raven.i.defaultvalue.org (Postfix, from userid 1000) id 6763C1C8F1; Thu, 7 Nov 2002 21:11:17 -0600 (CST) Original-To: Dirk Herrmann In-Reply-To: (Dirk Herrmann's message of "Thu, 7 Nov 2002 18:52:28 +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:1666 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1666 Dirk Herrmann writes: > But: How should a memoizer that is performed _before_ execution know what > will be correct? How should it know whether there will be a binding for > '=>? It seems like it can't in that case. I'm not entirely clear on the issues involved here, but I'd like to be, so please bear with me. Would it be possible (and make any sense) to arrange for something like like "just in time" memoization for top-level forms (as I think Clinton may have suggested), or would that overly complicate the code? i.e. don't memoize top-level expressions until you're ready to execute them. Such an approach might prevent those bits from being compiled efficiently, but I suppose the user could choose whether or not to write things that way. There's still the question of whether or not we should even allow non-top-level defines like this, although I can understand the impulse, esp for configuration related decisions. I'd say if supporting them leads to really nasty semantic or implementational complexities, especially if given suitable alternatives, then perhaps we shouldn't. Also, would eval-when based defines still be OK? I would presume so, since they're essentially a conditionally included "begin block". (eval-when (compile) (define => bar)) > a) be incompatible with R5RS. This will, however, require us to make it > clear for users of guile where and how we deviate from R5RS. Taking > this option will also imply that our macros are not really hygienic. > It also means that an interpreted system will behave different than a > compiled or memoized system, even if there are no uses of eval or > load. Hope we can avoid that one. > b) complicate the memoization process in order to get things right. An > option that we have here is the following: Top-level forms are not > memoized but interpreted. Memoization is only done whenever a > non-top-level scope is entered, like a let-form, or a > lambda-expression. The cost of this solution is that in addition to > the memoizer and the executor we would need an interpreter. Why are let forms and lambda expressions excluded? -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel