Re: Rscheme etc.

Per Bothner (bothner@cygnus.com)
Fri, 10 Nov 95 13:38:53 -0800

> For example, a compiler implementor might look at the upcoming
> reference manual, and derive a spec that says "If you limit your use
> of Guile to just features X,Y and Z...we're able to compile your
> program into a <shared object file | dynamicly loaded object file |
> bytecodes> that can be loaded into Guile. Of course if you use
> <low-level macros | the top-level as a first-class module | etc.> then
> all bets are off.

I'm confused. Are you talking about source compatibility or binary
compatibility? I think working on source compatibility makes a lot
of sense. (This includes not just Scheme code, but also a common
C API.)

However, binary compatibility seems impractical. Scheme implementations
use very different object representations. This is fundamental:
You can't call RScheme-compiled functions from SCM or vice-versa
unless they have the same object representation and layout.
There are other problems, such as incompatible calling conventions,
evaluations mechanism, stack usage conventions, and GC; those could
perhaps be dealt with with suitable glue code, though it would be a
lot of pain.

--Per