[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: handling multiple scheme instances

This page is part of the web mail archives of SRFI 50 from before July 7th, 2015. The new archives for SRFI 50 contain all messages, not just those from before July 7th, 2015.

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.