guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

expanding the guile-vm closure to include goops?


From: Andy Wingo
Subject: expanding the guile-vm closure to include goops?
Date: Fri, 02 May 2008 18:33:31 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)

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/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]