For those who have lost count of the zillions of languages out there, this is a Scheme interpreter/vm that was supposed to become the "official" extension language for GNU projects. It had some publicity in the 90s, but slowed down until recently.
Sorry to be simplistic, but so many links here assume everyone is an expert in functional programming; a little context helps everyone understand the importance of a post.
I still don't understand Guile. It makes sense as a stand-alone language implementation, but not as an embeddable one. Why isn't it re-entrant? What about multiple interpreters? Why a C-level GC like Boehm, rather than just track your own garbage? Why scheme for an embeddable language, don't continuations make C interop hard?
Even back when they announced Guile, it seemed odd that they based it on SCM rather than on SIOD or TinyScheme.
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.
>> 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, 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.
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.
-At that time Tcl was being developed by an Evil company: Sun Microsystems.
At the time, TCL was being pushed heavily for this purpose. I had a very low opinion of TCL, basically because it wasn't Lisp. It looks a tiny bit like Lisp, but semantically it isn't, and it's not as clean. Then someone showed me an ad where Sun was trying to hire somebody to work on TCL to make it the “de-facto standard extension language” of the world. And I thought, “We've got to stop that from happening.” So we started to make Scheme the standard extensibility language for GNU. Not Common Lisp, because it was too large. The idea was that we would have a Scheme interpreter designed to be linked into applications in the same way TCL was linked into applications. We would then recommend that as the preferred extensibility package for all GNU programs.
This is not true. Isn't it obvious that "basically because it wasn't Lisp" is shorthand for "because of a bunch of respects in which it differs from Lisp and Lisp is better"?
Note that the comment you're replying to links to RMS's more complete account of "why you should not use Tcl", which lists a number of respects in which he considers that Tcl is not suitable as an extension language. For instance: "It lacks arrays; it lacks structures from which you can make linked lists. It fakes having numbers, which works, but has to be slow." And: "Tcl has a peculiar syntax that appeals to hackers because of its simplicity. But Tcl syntax seems strange to most users." (Yes, it is kinda ironic that he said that and then proposed using Scheme. But, as he said at the time, the intention was to have two syntaxes with the same semantics, one of them Lispy and one more conventionally "algebraic".)
RMS also did not say that "Tcl was being developed by an Evil company", nor that that was a reason for discouraging its use. He said: He didn't like Tcl; Sun were trying to get Tcl made the de facto standard extension language; he wanted to make sure that didn't happen. There's no suggestion at all that he wanted to stop it happening because Sun were evil.
Have you seen multiple kLOC tcl apps? I have, and it is not pretty :)
Thing about extension languages is that they tend to be nice languages to write code, so people write a lot of code in them, and suddenly your app is 95% written in the extension language. Scheme is the language I know that grows best from a simple extension language to a full-fledged mature programming language.
Tcl has been improved a lot since the Tcl War (17 years ago!) including namespaces, module/package system, a native OO, a sane thread support, and Dicts. I am not sure if it is still true that Tcl doesn't scale well.
If it's a large tcl "app", then quite often that's the first mistake. I've seen large Tcl systems which work pretty well. A combination of different applications, cron jobs, scripts etc., with some C/C++ libraries for integration and performance-critical things. With the added benefit of having a pretty decent graphical toolkit on top. Won't be the winner of a GUI beauty pageant, but it works.
And most of those systems were pretty old, so it's not like you had a lot of better options back in the days. Tcl was pretty awesome in the mid-90s.
Most Java programs that replaced those enterprise tcl systems were a lot worse than their predecessors.
An excerpt, which (imo) should be quoted more often
"Language designers love to argue about why this language or that language must be better or worse a priori, but none of these arguments really matter a lot. Ultimately all language issues get settled when users vote with their feet. If Tcl makes people more productive then they will use
it; when some other language comes along that is better (or if it is here already), then people will switch to that language. This is The Law, and it is good. The Law says to me that Scheme (or any other Lisp dialect) is probably not the "right" language: too many people have voted with their feet over the last 30 years. I encourage all Tcl
dis-believers to produce the "right" language(s), make them publically available, and let them be judged according to The Law."
This isn't exactly the right place to ask this sort of questions. Why not email your distro's guile maintainer? Or open a bug report. Or just search for an already existing discussion on this topic on Debian's usual maintainer communication channels.
If the author thinks others might be interested in the answer, this is exactly the right place for this type of question. Sure, it's not going to get upvoted to the top of the page, but it's the type of constructive question and answer that belongs near the bottom of a comment thread. Both Debian & Guile are interesting to hackers, and there would be a large overlap between the type of hackers interested in Debian and the type of hackers interested in Guile.
There's no real reason to expect that it wouldn't make it in. Squeeze was just promoted to Stable, so Wheezy should remain unfrozen for months to come. That's ample time to bring in guile-2.0 during the normal migration of packages from Unstable to Testing.
Scsh: There was a whole lot of noise and some code about supporting Scsh on Guile early last decade, as there was for PLT Scheme, but both seem to have run out of steam. I think that replicating Scsh is harder than it looked at first.
I'm really pleased to see the work on the command language and bytecode interpreter. Scsh is something I've built a few times, but never got into. First the sounds of progress on the Emacs/guile front and now this look positive: it's a good time to take another look at Guile.