From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Marius Vollmer Newsgroups: gmane.lisp.guile.devel Subject: Re: Syntax checks Date: 07 Apr 2002 12:40:05 +0200 Sender: guile-devel-admin@gnu.org Message-ID: <87d6xb3i7u.fsf@zagadka.ping.de> References: NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1018175965 22914 127.0.0.1 (7 Apr 2002 10:39:25 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 7 Apr 2002 10:39:25 +0000 (UTC) Original-Received: from fencepost.gnu.org ([199.232.76.164]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 16uA4z-0005xM-00 for ; Sun, 07 Apr 2002 12:39:25 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16uA4f-0004eW-00; Sun, 07 Apr 2002 06:39:05 -0400 Original-Received: from dialin.speedway42.dip219.dokom.de ([195.138.42.219] helo=zagadka.ping.de) by fencepost.gnu.org with smtp (Exim 3.34 #1 (Debian)) id 16uA2r-0004SH-00 for ; Sun, 07 Apr 2002 06:37:13 -0400 Original-Received: (qmail 1255 invoked by uid 1000); 7 Apr 2002 10:40:05 -0000 Original-To: Guile Development List In-Reply-To: Original-Lines: 61 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 Errors-To: guile-devel-admin@gnu.org X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.0.8 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:317 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:317 Neil Jerram writes: > Also, does this fit into a more general picture of how we should > evolve the interactions between transformation, evaluation, > compilation etc.? (I don't claim that such a picture exists, but it > would be nicer if it did.) I have a dimm picture of a compilation framework in my head. Here is what I wrote about it in a mail to Rob: But having a compiler for Guile is still an important goal, but we should do it Right rather than rush it. I plan to attack it from above, by first straighten out the module system to be friendly to compiler semantics, redoing our current memoizer to be no longer tangled with the evaluator and then having a way to write memoized code to disk and load it back in. Down that road are enough design problems that are important for good compiler support, long before we come close to worrying about how to produce native machine code (or even cross compiling). When we are able to write memoized code to disk and this does indeed speed up loading, we can make syntax-case our standard macro expander and the memoizer wouldn't have to work with macros at all. We could then also move GOOPS even closer to the core [because it will load in tolerable time], using it for ports and the exception system, for example. Maybe even throw out smobs. Then (if development is linear, which it needn't be of course), we can seriously think about compiling to machine code, by offering a choice between the memorizer and other code generators. [...] I would like to follow the path outlined above. Hobbit would enter quite late, and would have to handle macros at all. It would get expanded code with certain additional guarantees (i.e. unique variable names, correct syntax, only a few core forms, maybe even some special language that isn't Scheme). > It's not clear that full expansion at compile time is always > acceptable since it looks like, given Guile's current API, > people could have been using the macro system as a simple way to > write memoized code for dynamic programming, which shouldn't be > fully expanded at compile-time. I don't think we want to support that. That practice would be even worse than unmotivated use of eval and instead of letting people get away with it, we should educate them. > And of course there's a whole raft of other issues related to > how macros and compilation should interact. i.e. Common Lisp will offer good hints, I guess. This is what I want to iron out when separating the memoizer from the evaluator. I want to make these questions 'central' to Guile, that is, the basic semantics of Guile are affected by this, not just the odd-ball compiler user. This will ensure that compilation is consistent with using Guile interactively. So I see Dirk's syntax check cleanups as steps towards a separation of the memoizer and the executor. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel