From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andy Wingo Newsgroups: gmane.lisp.guile.devel Subject: Re: srfi-18 and the vm Date: Sat, 23 May 2009 18:38:33 +0200 Message-ID: References: <878wko16zz.fsf@arudy.ossau.uklinux.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1243098589 26481 80.91.229.12 (23 May 2009 17:09:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 23 May 2009 17:09:49 +0000 (UTC) Cc: guile-devel To: Neil Jerram Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sat May 23 19:09:42 2009 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1M7uj7-0004TY-S1 for guile-devel@m.gmane.org; Sat, 23 May 2009 19:09:42 +0200 Original-Received: from localhost ([127.0.0.1]:48446 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M7uj7-0004Gr-Cr for guile-devel@m.gmane.org; Sat, 23 May 2009 13:09:41 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M7uj0-0004G9-51 for guile-devel@gnu.org; Sat, 23 May 2009 13:09:34 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M7uiv-0004EQ-KL for guile-devel@gnu.org; Sat, 23 May 2009 13:09:33 -0400 Original-Received: from [199.232.76.173] (port=38961 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M7uiv-0004EJ-Ct for guile-devel@gnu.org; Sat, 23 May 2009 13:09:29 -0400 Original-Received: from a-sasl-quonix.sasl.smtp.pobox.com ([208.72.237.25]:49771 helo=sasl.smtp.pobox.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M7uiu-0005Ai-RP for guile-devel@gnu.org; Sat, 23 May 2009 13:09:28 -0400 Original-Received: from localhost.localdomain (unknown [127.0.0.1]) by a-sasl-quonix.sasl.smtp.pobox.com (Postfix) with ESMTP id 7956319BB8; Sat, 23 May 2009 13:08:58 -0400 (EDT) Original-Received: from unquote (unknown [79.151.217.76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-sasl-quonix.sasl.smtp.pobox.com (Postfix) with ESMTPSA id 71B0819BB7; Sat, 23 May 2009 13:08:56 -0400 (EDT) In-Reply-To: <878wko16zz.fsf@arudy.ossau.uklinux.net> (Neil Jerram's message of "Sat, 23 May 2009 10:52:16 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (gnu/linux) X-Pobox-Relay-ID: 6793BA2A-47BC-11DE-8B72-B4FDD46C8AFF-02397024!a-sasl-quonix.pobox.com X-detected-operating-system: by monty-python.gnu.org: Solaris 10 (beta) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:8509 Archived-At: Hi Neil, On Sat 23 May 2009 11:52, Neil Jerram writes: > Andy Wingo writes: > >> With psyntax running a pre-analysis phase on all source code, we can do >> away with lazy memoization entirely -- a neat hack, but it made eval.c >> buggy and impenetrable. I'll write more about that in the future. > > Anticipating your "more in the future", do you mean that the > pre-analysis does all the memoization in advance? It does not now, but it could. All output from psyntax is created by this set of procedures (internal to psyntax.scm): build-void build-application build-conditional build-lexical-reference build-lexical-assignment build-global-reference build-global-assignment build-global-definition build-lambda build-primref build-data build-sequence build-let build-named-let build-letrec In compile mode, these procedures create tree-il objects. In eval mode, they create s-expressions, so that the expander can work before modules are booted. (The mode is the second parameter to sc-expand; it's eval mode by default, but the compiler sets it to compile mode.) One should be able to memoize ilocs in from the result of the output, in a second pass, given that there are so few forms. Of course some memoization can happen lazily too, e.g. global lookup; but macros have already been expanded out, so the evaluator doesn't have to know about `cond' or `do' or anything else, and unmemoization becomes trivial. The evaluator can be drastically simplified, which is good for maintainance. It will probably be faster too. Then, later on, we can implement and compile an evaluator in Scheme itself, so that we can tail call between interpreted and compiled code. (We're not limited to just 2 passes, even in the interpreter, of course; once we have an inliner, it would probably be a good idea to run it on code for interpretation, as well.) What do you think? Andy -- http://wingolog.org/