[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: handling multiple scheme instances
Shiro Kawai <shiro@xxxxxxxx> writes:
> > Every function should take an extra parameter which represents the
> > particular Scheme instance under consideration. I might be running
> > two different Scheme worlds in one process.
> To what extent should those Scheme instances share?
> (a) addess space : whether a reference to an object from one
> world can be passed to another world.
> (b) binding name space (symbol -> global variable mapping) :
> whether a global binding in one world is visible
> to another world or not.
> (c) control flow and data stack : whether you can "fork" a
> world to two worlds sharing the activation records.
> Related to this, I think the API concerning global bindings
> should take a context information corresponding to (b)---e.g.
> my Scheme needs "module" argument to determine which global
> binding the name refers.
We don't need all that in the bindings. Different Schemes might
provide more or less of this flexibility. A single "context"
parameter is quite sufficient; a Scheme that supports multiple
instances in one process, or distinct binding spaces, and so forth,
can all be hidden inside that context.
A later standardization might provide for fetching particular things
out of that context. But I think Tom Lord's point is just that we
need *some* extra parameter; it can be entirely opaque from a
standardization perspective, and still be pretty useful.