expanding the guile-vm closure to include goops?

expanding the guile-vm closure to include goops?

[Andy Wingo]

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/

Re: expanding the guile-vm closure to include goops?

[Ludovic Courtès]

Hi,

Andy Wingo <wingo@pobox.com> writes:

> 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.

Exactly.  A related message was this:
http://thread.gmane.org/gmane.lisp.guile.devel/6015 .  I had just read
Flatt's paper, which led me to think we really needed a variant of
`use-modules' to specify modules that are used only at compile-time, for
their macros.

> But: until then, bringing in SRFI-9 records would break the
> self-compilability of guile-vm. 

... which isn't much of a problem I suppose.  :-)  Moving to SRFI-9 looks
like a good idea to me.

> 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.

I'm not sure.  I'd prefer to use plain Scheme with SRFI-9 records in the
compiler since using GOOPS may not buy us much.

Thanks,
Ludovic.