[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.