Re: [Chicken-users] External representation for continuations

[Thomas Chust]

felix wrote:
> Thomas Chust wrote:
>
> > Information like that already exists in every file compiled with 
> > debugging information, so perhaps one would be able to access it 
> > without too much trouble. The bigger problem will probably be the 
> > serialization of code that is dynamically loaded or generated at 
> > runtime, because it also requires transmission of the code itself, not 
> > only of an identifier.
>
>
> I'm not sure whether using debugging info is the best solution:
>
> a) `strip' will render an executable without any serialization info
> b) it would be dependent on the deug-info format
> c) it wouldn't be very portable (say, to the MSVC toolchain)
>
> Code generated at runtime doesn't happen yet (besided evaluated code,
> and here the C procedures are already there and should be just as
> serializable as compiled closures). Dynamic wouldn't be problematic
> either, provided we require the deserializing process has loaded the
> same modules.

Sorry for the stupid question, but what does CHICKEN make of an (eval 
(read)) in compiled code? I don't quite understand what you mean by "the 
C procedures are already there".

> [...]
> > The problem with the environment was solved in the original Kali 
> > Scheme implementation (which was implemented on a stack based Scheme) 
> > by only transmitting the top few stackframes with a continuation and 
> > loading more frames over the network if they were actually needed. 
> > This is reasonable for example when migrating tasks across a network. 
> > I have no idea how to port this concept to CHICKEN, though.
>
> Neither do I. But the idea is clever. The SISC people have serializable
> continuations, I should get into contact with Scott Miller about this and
> ask how they handle this particular issue.

Hmm, I just tried it out with the last SISC release -- serializing a 
continuation works all right, but deserializing it crashes the 
interpreter :-( De-/Serializing procedures and other stuff works fine, 
though.

I'd actually be interested in the code of the original Kali Scheme 
implementation (which was based on Scheme 48). But it seems to be no 
longer available for download...

> [...]

cu,
Thomas