mlton

[Stephen Weeks]

> Just one more question. SML/NJ has call/cc implemented (fairly easy in
> their totally heap-based runtime-system). Do you consider implementing it
> in mlton? I know it is slightly more complicated in stack-based model, but
> scheme48 for instance has it. 

I think it would be easy (i.e. less than 1 day) to put in a simple
implementation of call/cc that copies the entire stack into a heap
object whenever you call call/cc and copies the entire heap object
back to the stack whenever you invoke a continuation.  The main
difficulty would be adding a new kind of object recognized by runtime
system, so that the pointers in the stack to other heap objects and to
the stack object itself can be updated when doing a garbage
collection.

The advantage of such an implementation is that it has little (but not
zero, because of a test in the gc) cost to programmers that don't use
call/cc.  I'm not sure if such a simple implementation would be usable
for the application you envision.  The copying of the stack will be
especially costly in the current implementation of mlton since the
backend doesn't do any sharing of stack slots, hence the stack frames
and the stack are unnecessarily large.

Let me know if such a simple implementation is useful to you and I'll
think more about putting it in.

Also, I am leaving NEC at the end of this week to take a new job.  I
will still be working some of the time on mlton, but not nearly as
much.  It's probably best to send email to (or at least cc)
mlton@research.nj.nec.com because mail there goes to me as well as to
others working on mlton (for now, henry@research.nj.nec.com and suresh
@research.nj.nec.com).  Or, if you think it may be of general
interest, mlton-discuss is fine too.  Thanks.