[racket-dev] using Racket to build an image-based Lisp: feasible?

At Mon, 04 Mar 2013 08:50:19 -0600, mikel evins wrote:
> Is the bytecode format platform-independent?

Yes.

> Is it documented? I guess I probably won't need to know gory details
> about the bytecode format, but I could be wrong.

The gory encoding details are not documented, but the documentation of
`compile/zo-structs' is essentially documentation of the data
structure.

The `compiler/zo-parse' and `compiler/zo-marshal' provide functions for
parsing and writing bytecode in terms of the `compile/zo-structs'
structures.

> Does fasl serialization use the bytecode format? 

Yes.

> Do you see serious problems with building a solution based on
> serialization and fasls?

No --- that seems like the way to go.


> I used to work with Will Clinger and John Ulrich's MacScheme; it had the nice 
> feature of supporting a free mixture of bytecode and native-code procedures. 
> Is that a doable thing in Racket, either as it stands right now, or as a 
> feature that could be added without a lot of trouble?

The bytecode format doesn't have a nice way to do that, currently. (You
can put a native-code shared library in place of a bytecode
implementation of a module, but I don't think that's what you want.)
I'm not sure what it would mean to mix native-code procedures with
bytecode --- where the procedures would come from, for example --- so
I'm not how difficult it would be to support.


Your project sounds really interesting --- not only on its own terms,
but to me, also as an experiment in driving Racket in a new direction.
So far, we have pursed a path at the opposite end of the design
spectrum from Smalltalk and Lisp images (e.g., with modules, phases,
and separate module instantiations across phases in Racket). It would
be great to have a path to the other side. I think Liitin[1] maybe has
similar goals, and maybe there's an opportunity for some shared
infrastructure.

[1] http://lists.racket-lang.org/users/archive/2011-January/043691.html