[pypy-dev] Continuations and sandboxing

[William ML Leslie]

Fijal is right, fwiw.  There are lots of wonderful things that *could*
be implemented, but what we *have* is the stackless transformation and
a low-level sandbox system.  Discussions of python architecture are
always enjoyable, but they don't have a proper place, as far as I
know; I often abuse #python for that.

On 11 January 2011 22:03, Laura Creighton <lac at openend.se> wrote:
> When I was last in the USA, I met Alessandro Warth, who now works for
> the Viewpoints Research Institute and whose Phd thesis which you can get
> on this page: http://www.tinlizzie.org/~awarth/ is about experiments in
> computer languages to do the sorts of things that you are interested in.
> He had a neat implementation of something he called 'worlds' to show off,
> and gave a talk about it.  It's chapter 4 of his thesis.

I first read this paper as background for pymeta - it's one of those
that you just can't put down.  There is one thing I felt was missing
from the worlds thesis though, namely, handling arrays.  To treat them
like any other ecmascript object results in strange semantics - if two
worlds push to the one array and both are merged, it is as if only one
of the pushes occurred.  Python lists have different usage patterns
than javascript objects, so handling their diffs correctly and
efficiently might require some experiments.

> They concluded that what they would really like is a programming language
> which multiple heaps -- in the sense of chunks of memory that you get
> when you malloc -- guaranteed to be separate from each other.  I couldn't
> tell them how hard this would be to implement in PyPy.  Aside from needing
> to write a custom garbage collector, what else would be needed?

How would that be different to separate pypy processes? Or is that
more like regions in cyclone, or like subinterpreters in TCL?

-- 
William Leslie

PS: worlds are an ideal use case for first-class algebraic effects!