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: expansion, memoization, and evaluation... Date: Tue, 03 Dec 2002 20:41:47 -0600 Sender: guile-devel-admin@gnu.org Message-ID: <87r8cyh5ec.fsf@raven.i.defaultvalue.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1038969737 11128 80.91.224.249 (4 Dec 2002 02:42:17 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 4 Dec 2002 02:42:17 +0000 (UTC) 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 18JPUM-0002sy-00 for ; Wed, 04 Dec 2002 03:42:14 +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 18JPUJ-00050t-00; Tue, 03 Dec 2002 21:42:11 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18JPU0-00041G-00 for guile-devel@gnu.org; Tue, 03 Dec 2002 21:41:52 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18JPTw-0003qZ-00 for guile-devel@gnu.org; Tue, 03 Dec 2002 21:41:50 -0500 Original-Received: from n66644228.ipcdsl.net ([66.64.4.228] helo=defaultvalue.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18JPTv-0003o8-00 for guile-devel@gnu.org; Tue, 03 Dec 2002 21:41:48 -0500 Original-Received: from raven.i.defaultvalue.org (raven.i.defaultvalue.org [192.168.1.7]) by defaultvalue.org (Postfix) with ESMTP id 49CB510D73 for ; Tue, 3 Dec 2002 20:41:47 -0600 (CST) Original-Received: by raven.i.defaultvalue.org (Postfix, from userid 1000) id 29E3E8BEA9; Tue, 3 Dec 2002 20:41:47 -0600 (CST) Original-To: guile-devel@gnu.org 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:1787 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1787 I thought it might be worthwhile if I made my support of Dirk's recent work, and my current feelings about the related issues clear, though I'm certainly ready and willing to change my position(s) if appropriate. ATM I'd really like to see guile make a clean separation between stages of evaluation. Dirk has suggested perhaps four stages: expansion (scheme->intermediate code) compilation (intermediate->intermediate) memoization-or-compilation (intermediate->{memoized,compiled}) execution That arrangement seems like a pretty good initial goal, though I realize that it may or may not end up being the "final arrangement". ISTR that some people were concerned that having a separate expansion stage might cause a performance loss. My current feeling is that - if the performance hit is minimal, and will go away when we can write/read pre-expanded (perhaps our first version of .scmc files :>) code, then I'd be tempted to just ignore the loss. I feel like the increased clarity of the process, and the potential for optimizations/plugging in other compilers, etc. will be likely to outweigh the loss. Also note that if we have a point where it's easy to get access to the post-expansion, but pre-memoization code, it becomes *much* easier to add strong, offline compilation to guile. As an example, my impression is that one of hobbit's biggest issues has been dealing with macros (define-macro vs defmacro vs syncase). If hobbit can be handed the pre-expanded code, it can completely ignore macros. - if the performance hit is not minimal, but if it's not all that hard to add a #define SCM_I_BUILD_WITH_SEPARATE_EXPANSION_STEP, then perhaps that would be a good approach for the short term -- you'd only enable that option if you were experimenting, if you were a guile offline compiler, or if you had finally finished a compiler whose performance improvements dwarfed the "separate step performance loss". Ideally we'll pick up more than enough performance improvements elsewhere, given a cleaner infrastructure for people to hack on (i.e. one that's approachable by more people) to outweigh the performance loss that having separate evaluation stages might entail. Another thing I'd like to suggest is that when considering things like whether or not we should have unmemoization, first-class macros, etc., we consider how these things might affect an offline compiler. If nothing else, we may not want to structure guile in such a way that we provide mechanisms that preclude the code from ever being able to be compiled offline. Part of the answer is to use eval-when (or eval-case) appropriately. Also, though we can structure guile's macros (and other things) to be arbitrarily dynamic, that doesn't mean we should. Aside from the performance costs involved, I feel like we ought to keep an eye on how our choices affect both the comprehensibility of our implementation and the scheme code that the end-user may write. WRT macros, my general impression is that unless you are very clear about the semantics of your macro system and your evaluation process, and unless you're reasonably strict in what you allow, you're likely to preclude much serious compilation because the compiler won't have the assurances it needs in order to be able to make many substantial optimizations. i.e. if you're not careful you can end up with the compiler having to just convert (foo bar baz) into (eval '(foo bar baz)) or similar, far more often than you'd like, because the compiler can't be "sure enough" about foo, bar, or baz. -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel