Fri Aug 14 08:48:30 CEST 2009
Moving the stack language into the Scheme interpreter.
Basic idea: the PF machine never CONSes from the GC free space for
_data_ objects. It's CONS is a reusing one.
What about doing this differently: separate out the memory model from
the scheme struct. This includes GC and all leaf object classes.
The thing to decide is which objects are allowed in the stack machine
as data objects, and which should remain hidden. There's no use for
exporting the Scheme's internal data structures (yet). Let's start
with cons cells and atoms. Maybe the main problem is representing
RC'd atoms in the Scheme core.
It doesn't seem to be necessary to run PF in SC. As long as the
memory management is compatible, they can be made to work together.
The hairy part is the GC restart, since they would need to share the
GC next to all the mem classes, but it doesn't seem infeasible.
So, given that we're using the Scheme's data model, how should
finalization and reference counting be bridged?