Re: guile/workbook/extension/dynamic-root.text

[Tom Lord]

What do you think of moving to a _stackless_ execution model?  In 
a stackless model, eval would never call itself recursively
and a single scheme computation could be resumed from multiple
C stacks or multiple frames in a given C stack.  In a stackless model,
the conservative part of `gc' could be removed.  In a stackless model,
it would be possible to implement a symbolic debugger with _no_
run-time overhead cost.

In a stackless implementation, call/cc would be very fast.

In a stackless implementation, since you can easily have precise GC,
you can easily have _incremental gc_.

With a stackless implementation, you can easily make the interpreter 
single threaded (simplifying programming) but able to multiplex
several real threads by rapidly context switching at virtual
instruction boundaries.  Since it's stackless, those context switches
can be very cheap.

There is a smooth migration path:  if you start by making `eval' and
`apply' stackless, you can still provide "backwards compatible"
interfaces for built-ins that expect a stack-full, conservative-GC
system.  You can gradually fix such built-ins in the core, and perhaps
eventually deprecate the compatability interface.

The big catch: In a stackless implementation, built-ins would no
longer be allowed to call `eval' or `apply' -- they would instead have
to be split up into multiple C functions.  Believe I know that
sometimes the C friendly calling conventions inherited from SCM are
the big win of Guile -- but personally I'm skeptical: I think a
stackless implementation can also be easy to use and will have much
nicer performance and robustness characteristics.

All of this is roughly my plan for systas, which I still sometimes
think about unforking with guile.  I think that guile hackers might
enjoy exploring the wiki running on systas at:

      
http://www.regexps.com/labnotes/devo-meta-x/view-topic/---cgi---/---index---

-t