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: Sat, 09 Nov 2002 11:08:08 -0600 Sender: guile-devel-admin@gnu.org Message-ID: <87el9usmbr.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 1036863018 6219 80.91.224.249 (9 Nov 2002 17:30:18 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sat, 9 Nov 2002 17:30:18 +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 18AZQy-0001bI-00 for ; Sat, 09 Nov 2002 18:30:12 +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 18AZIK-0001d1-00; Sat, 09 Nov 2002 12:21:16 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 18AZ6A-0004WH-00 for guile-devel@gnu.org; Sat, 09 Nov 2002 12:08:42 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 18AZ5e-0004TJ-00 for guile-devel@gnu.org; Sat, 09 Nov 2002 12:08:41 -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 18AZ5e-0004TF-00 for guile-devel@gnu.org; Sat, 09 Nov 2002 12:08:10 -0500 Original-Received: from raven.i.defaultvalue.org (raven.i.defaultvalue.org [192.168.1.7]) by defaultvalue.org (Postfix) with ESMTP id 2421A1C6D; Sat, 9 Nov 2002 11:08:09 -0600 (CST) Original-Received: by raven.i.defaultvalue.org (Postfix, from userid 1000) id 0DE911D840; Sat, 9 Nov 2002 11:08:08 -0600 (CST) Original-To: Dirk Herrmann In-Reply-To: (Dirk Herrmann's message of "Sat, 9 Nov 2002 10:00:49 +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:1676 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1676 Dirk Herrmann writes: > On-the-fly memoization is what guile currently does. This does, > however, slow down evaluation, it complicates the evaluator and it > does not allow us to write out pre-compiled code in order to speed > up startup time. OK, that's pretty much what I expected. > It took me quite some time to understand the issues involved with > conditional definitions. My current effort to separate memoization > and execution made it clearer to me, because it reflects itself in > the code for the evaluator if you want to do things right. This > made me see one thing: The design decisions hidden in R5RS are > typically based on very thorough investigations of potential > problems. Implementations have to be very careful to deviate from > these decisions. No argument here. That's my default assumption as well. > the cond-expression should be memoized. However, for eval it is IMO > easier to communicate the problems involved when distinguishing > compilation and interpretation: When using eval, people typically > understand that the evaluated expression can not be pre-compiled. In > contrast, conditional definitions seem so natural that people will > probably not be aware of the problems that are involved. Agreed. I'd definitely like to err on the side of making complicated things clearer, so I'd favor making eval explicit as you suggest, and (as I've probably said elsewhere) I'd definitely like to avoid clevernesses or conveniences that make it harder know when you're writing code that can be optimized. > It should be noted that internal definitions may also only occur at a > restricted set of places. For example, even the current guile (which > allows conditional defines on the top level) does not support the > following: > (lambda foo > (if (define ))) Ahh, that's what was confusing me. I took your "let's are ok" too broadly and I was wondering why (let () (if (define => #t)) (cond (#t => 'ok))) would be fine. Since that's not fine, I'm not confused :> Thanks for the explanations. -- 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