3 ms·
I did a very similar thing with a python-implemented LISP interpreter, mainly so that I could implement a trampoline so I could do tail call optimization. It re
by gliese1337 14y ago
I did a very similar thing with a python-implemented LISP interpreter, mainly so that I could implement a trampoline so I could do tail call optimization. It required CPSing the interpreter (and built-in functions), but not the interpreted program- this works because the continuation of the interpreted program is contained in the continuation of the interpreter that runs it. The interpreted "stack" ends up as a chain of Python closures.
You might be able to get away with compiling a runtime environment slightly more complex than your simple trampoline loop that does the same thing, building a chain of JavaScript closures to represent continuations without actually CPSing the rest of the program. Continuation calls would then show up on the JavaScript stack and allow you to step through them.
- jlongster 14y agoWouldn't that be even slow though? Not only is it CPS code, but it's a program being interpreted by CPS code. I think I see what you're getting at though. Sounds neat; I definitely have a lot of new ideas for implementing CPS in a performant way now. Outlet is a compiler which compiles straight to js, no interpretation.
- gliese1337 14y agoNot sure; I haven't got anything to benchmark my implementation against. My suspicion is that it would be faster because you get chains of interpreted-continuations-implemented-as-interpreting-closures that call each other normally, rather than trampolining absolutely everything. But I would not be surprised if I turn out to be completely wrong about that. > Outlet is a compiler which compiles straight to js, no interpretation. Right; hence, you would have to include the implementation of the CPSed run time environment in the compiled output, just as you have to include the extra trampoline function when you do the current CPS transform.