Re: New Guile VM

[Mikael Djurfeldt <mdj at mdj dot nada dot kth dot se>]

Keisuke Nishida <kxn30@po.cwru.edu> writes:

> How would you draw a road map toward the new interpreter?

Originally (before I became a Guile maintainer), my plan was to
develop the interpreter in parallel to Guile development and then
propose a switch when it had reached some level of maturity.

Now many things have changed for me and I don't have as much time as I
didn't have previously.

So, the reason why I put the sketch in guile-core/devel was not a
concrete plan to realize this interpreter.  I just thought that some
of the ideas of how it uses the stack could be interesting for you
now.  Maybe it isn't very different from what you already have, but
this idea with a dynamic context block seems good.  The idea of
producing "branches" should be realizable some time after GOOPS
integration.

> I would suggest this:
>
>  1. Write a VM and a compiler that evaluates R5RS without modifying
>     the current Guile's core.
> 
>  2. Add a support for the current module system and a feature of
>     bytecode saving/loading to/from files.
> 
>     After this, a VM version of Guile 1.4.x can be released
>     (if it is desirable).
> 
>  3. Add a support for GOOPS.  After the integration of GOOPS,
>     the VM can be optimized for it.
> 
>  4. The support for the new module system will be here.
> 
>  5. The ior project will be after everything has come to work fine.

Sounds good to me, although I hope that some of this will be developed
in parallel.

> Optimizations like generating machine code can be done whenever
> it is appropriate.

Yes, but infrastructure needs to be planned taking this into account.