>> What about multiple interpreters?
>
> Like arenas? Guile doesn't do this, no. I've never
> understood the desire for this, either; if you want to
> isolate users, put them in different modules.
I think he means running two interpreters in the same address space and/or thread. In Lua, a pointer to the entire interpreter state is passed around in a ``lua_State * ``, so it's easy to embed without worrying about one interpreter accidentally mucking with another. I believe Python does something similar with ``PyInterpreterState * ``.
Based on the Guile API reference[1], it's not possible to safely run two Guile interpreters in the same pthread. This makes it difficult to embed in languages with alternative threading models.
I've grown more and more averse to implicit state. I like that in Lua, all my interactions with the interpreter are mediated by the lua_State. If I want to run two at once, I can. If I want to store a Lua object for later use, I can stash it in there. If I want to have a globally-available state for my programs, I can implement it myself as a global. Nothing is mucking around with the call stack looking for things that "look like a pointer."
A few years ago, I wanted to embed a scripting language into a monster of a multithreaded C++ application, which (oh joy) was using RogueWave threads rather than straight pthreads. I tried python, but couldn't figure out how to get the thread locking to work properly; python had its own ideas about how the threading should work.
Then, I tried Lua. With Lua, I could just implement a pool of properly-initialized interpreters, then assign them out to each thread on need. It worked very well.
Based on the Guile API reference[1], it's not possible to safely run two Guile interpreters in the same pthread. This makes it difficult to embed in languages with alternative threading models.
[1] http://www.gnu.org/software/guile/manual/html_node/Initializ...