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: expanding the guile-vm closure to include goops? Date: Fri, 02 May 2008 18:33:31 +0200 Message-ID: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1209746182 29116 80.91.229.12 (2 May 2008 16:36:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 2 May 2008 16:36:22 +0000 (UTC) To: guile-devel , Ludovic =?utf-8?Q?Court=C3=A8s?= Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri May 02 18:36:57 2008 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 1JryFi-00018s-Rk for guile-devel@m.gmane.org; Fri, 02 May 2008 18:36:55 +0200 Original-Received: from localhost ([127.0.0.1]:33077 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JryF1-0004lw-GD for guile-devel@m.gmane.org; Fri, 02 May 2008 12:36:11 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JryEu-0004jt-TU for guile-devel@gnu.org; Fri, 02 May 2008 12:36:04 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JryEu-0004jH-Dd for guile-devel@gnu.org; Fri, 02 May 2008 12:36:04 -0400 Original-Received: from [199.232.76.173] (port=35781 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JryEu-0004is-56 for guile-devel@gnu.org; Fri, 02 May 2008 12:36:04 -0400 Original-Received: from a-sasl-fastnet.sasl.smtp.pobox.com ([207.106.133.19] helo=sasl.smtp.pobox.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JryEk-0000HI-SL; Fri, 02 May 2008 12:35:55 -0400 Original-Received: from localhost.localdomain (localhost [127.0.0.1]) by a-sasl-fastnet.sasl.smtp.pobox.com (Postfix) with ESMTP id E8F072FB1; Fri, 2 May 2008 12:34:06 -0400 (EDT) Original-Received: from unquote (74.Red-80-24-4.staticIP.rima-tde.net [80.24.4.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-sasl-fastnet.sasl.smtp.pobox.com (Postfix) with ESMTP id 5A63E2FB0; Fri, 2 May 2008 12:34:05 -0400 (EDT) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-Pobox-Relay-ID: 957806B2-1865-11DD-AC5E-80001473D85F-02397024!a-sasl-fastnet.pobox.com X-detected-kernel: 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:7204 Archived-At: Hello, I have started to look at guile-vm. It's interesting -- the C code is among some of the best-looking that I have ever seen, the documentation is pretty OK, but there are some aspects of the middle bits that are odd. One strangeness is that guile-vm actually is written in dialect of guile that understands things like (+ foo.bar 4) and (set! qux.frob.boz 3). This is implemented with the `expand-dot!' syntax transformer in (system bsae syntax). I think it would be a good idea to start moving this towards more standard guile, not least because we need the module-transformer for (ice-9 syncase). So on my branch: http://wingolog.org/git/guile-vm.git I have started to redo the syntax transformer. But this raises the question about what to use for compound data types. Keisuke also rolls his own define-record, and the dot syntax is linked with that. Ideally we would want to some more standard compound data type infrastructure. We could replace it with srfi-9 records. However I see that there is a failing compilation test for srfi-9 records in the test suite, apparently there intentionally, because there is some problem involving compilation phases, modules, and macro expansion: essentially, the things that Flatt's paper solves. We will certainly need to fix that. I see that there is some motion that way. But: until then, bringing in SRFI-9 records would break the self-compilability of guile-vm. So another option would be to expand guile-vm to use GOOPS for its compound record types. I think this is quite a good idea in the medium term. But probably we shouldn't do it until we excise the use of procedure->memoizing-macro inside GOOPS. I guess that since GOOPS does some compilation itself, we should have a stable VM that works well with macros before retargetting GOOPS's compilation efforts to the VM. My proposal, then, is this: let's break guile-vm's self-compilability for now, rebasing it on top of standard srfi-9 records. Then, rewrite the dot-syntax stuff to use record accessors. Then I can start to think about other things. I'll be hacking on this, but I write for comment. Andy ps. There is a third possibility, regarding records: use Guile's procedural make-record-type and friends. -- http://wingolog.org/