4 ms·

You raise some interesting questions, and some misconceptions. It's an ugly format, but I'm going to respond point-by-point: > Why isn't it re-entrant? I'm n

by wingo 16y ago

You raise some interesting questions, and some misconceptions. It's an ugly format, but I'm going to respond point-by-point: > Why isn't it re-entrant? I'm not certain what you mean here; certainly you can call from C to Scheme to C to Scheme, and do so concurrently from multiple pthreads. > 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. > Why a C-level GC like Boehm, rather than just track your own garbage? Precisely for embeddability. Tracking your own garbage is hard in C. It's doable of course, but very error-prone. Guile's C API is pretty easy to use (IMO of course). > Why scheme for an embeddable language, don't continuations make C interop hard? We have continuation barriers, but it's true that our historical continuation implementation has been a stack-copying one. In 2.2 we are likely to move to a model where we just capture the Scheme stack. That said, delimited continuations are really the bee's knees. See "Prompts" in the manual for more. > Even back when they announced Guile, it seemed odd that they based it on SCM rather than on SIOD or TinyScheme. I think the thing was that folks wanted an implementation that could grow into something more substantial. Which leads to your next point: > Lua seems to be far superior for embedding. Guile seems big and invasive by comparison. The problem is that once you have a nice small language, you start to want to program more and more in it, and you end up with a nice medium-sized language. You can see that even now with Alex Shinn's Chibi. It seems to be a hump you have to grow over and then become a nice large language ;-) Lua is wonderful, and they are among the few groups I have heard of that manage to keep things small and lean. By all means, use it! But I think that in the end, most things tend towards something the size of Python, and for mostly good reasons.

jmillikin 16y ago
>> 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. [1] http://www.gnu.org/software/guile/manual/html_node/Initialization.html#Initialization http://www.gnu.org/software/guile/manual/html_node/Initializ...
- oddthink 16y ago
  Yes, that's it exactly. 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.
- gaius 16y ago
  Tcl also does this I believe.
oddthink 16y ago
I tried to address the re-entrant/multiple-interpreters issue in my response to jmillikin, so I won't repeat it here. The GC thing is a similar distaste for "magic." I like Lua's solution of just outright forbidding anyone from having a handle on a Lua object from outside Lua. You keep a string, or a key, or something, and use that to look up the object. Yes, it's more work some times, but it simplifies the conceptual overhead. Continuations are similar. I don't want my embedded language mucking around with the C stack. If that means that I don't get continuations, that I only get escaping continuations, or that I can't jump to a continuation across a C stack boundary, then I'm fine with that. For both GC and continuations, if the abstraction were 100% seamless, that would be one thing, but if I have two libraries, both of which are playing games (either using a Boehm-like collector, or odd stack manipulation, or the like), my experience is that they won't play well together. Basically, I like embedded languages that know their place and don't get uppity and try to interfere too much with the host. Language size is hard. I understand why a language would get bigger. Scheme is good, in that it has a good solid core, and then the rest can be in optional packages and libraries. The small core + libraries combination seems like the best way to go, but I'd rather have just plain small over big. I'm embedding; most of the work is in the host program. I'd love to find a Scheme implementation that felt Lua-like, but I've not found one yet. I'll have to check out Chibi.

by wingo 16y ago

jmillikin 16y ago

>> 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. [1] http://www.gnu.org/software/guile/manual/html_node/Initialization.html#Initialization http://www.gnu.org/software/guile/manual/html_node/Initializ...

oddthink 16y ago
Yes, that's it exactly. 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.
gaius 16y ago
Tcl also does this I believe.

oddthink 16y ago

I tried to address the re-entrant/multiple-interpreters issue in my response to jmillikin, so I won't repeat it here. The GC thing is a similar distaste for "magic." I like Lua's solution of just outright forbidding anyone from having a handle on a Lua object from outside Lua. You keep a string, or a key, or something, and use that to look up the object. Yes, it's more work some times, but it simplifies the conceptual overhead. Continuations are similar. I don't want my embedded language mucking around with the C stack. If that means that I don't get continuations, that I only get escaping continuations, or that I can't jump to a continuation across a C stack boundary, then I'm fine with that. For both GC and continuations, if the abstraction were 100% seamless, that would be one thing, but if I have two libraries, both of which are playing games (either using a Boehm-like collector, or odd stack manipulation, or the like), my experience is that they won't play well together. Basically, I like embedded languages that know their place and don't get uppity and try to interfere too much with the host. Language size is hard. I understand why a language would get bigger. Scheme is good, in that it has a good solid core, and then the rest can be in optional packages and libraries. The small core + libraries combination seems like the best way to go, but I'd rather have just plain small over big. I'm embedding; most of the work is in the host program. I'd love to find a Scheme implementation that felt Lua-like, but I've not found one yet. I'll have to check out Chibi.