Guile 2.0 is out
article.gmane.org
article.gmane.org
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.
Even back when they announced Guile, it seemed odd that they based it on SCM rather than on SIOD or TinyScheme.
Lua seems to be far superior for embedding. Guile seems big and invasive by comparison. It seems to be heading squarely for that awkward middle size between big/full-featured and small/light that hurt Tcl, as argued in http://journal.dedasys.com/2010/03/30/where-tcl-and-tk-went-... .
> 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.
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...
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.
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.
It would be very nice if someone could summarize the current state of the language, i.e. why one would use it instead of Racket or Gambit.
-Tcl is not Lisp.
-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.
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.
By the way I wrote a toy, buggy and ugly scheme implementation in pure Tcl a year ago: http://wiki.tcl.tk/25512
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.
For a new project? Maybe, maybe not.
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.
http://www.vanderburg.org/OldPages/Tcl/war/0009.html
I can't find where I'd seen it, but RMS certainly wasn't really keen on the idea of a BSD-licensed system becoming popular, either.
http://www.vanderburg.org/OldPages/Tcl/war/0009.html
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."
That part is actually not entirely true. Languages have positive network externalities, as well as some very serious lock-in (see: Cobol) and switching costs.
Guile hacker Andy Wingo (wingo on HN, hi!) gave a talk about this and other recent Guile developments, which I summarized (and linked) here: http://jugglingbits.wordpress.com/2010/04/19/andy-wingo-rece...
I would love to learn Scheme as my next hobby language and guile seems like the way to go with all the things that have started to happen with it lately.
Any link for all the things that have started to happen with it lately for those of us who are out of the loop?
There was also a previous discussion about guile's webby features: http://news.ycombinator.org/item?id=2017419
Is Guile a good Scheme to start off with when first learning Scheme?
Racket is what most people recommend for learning.
How does Guile compare to scsh these days?
Lots of the POSIX bits in Guile were inspired by scsh though, originally anyway. Most of those pieces are 10+ years old.
There are ports around for scsh; googling "guile scsh" will lead you to a few. But there is no proper package with a proper manual.
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.