An opinionated guide to Scheme implementations
wingolog.org
wingolog.org
My email is in my profile if you'd rather email me directly rather than dumping something controversial here.
"Syntax and Semantics of Programming Languages"
http://homepage.cs.uiowa.edu/~slonnegr/plf/Book/
this is a free version of:
http://www.amazon.com/Formal-Syntax-Semantics-Programming-La...
the implementations are in Prolog.
I sincerely hope that the new standard would help here. Splitting the language into a big and small system seems like a good compromise between the traditional scheme goal of minimalism and pragmatism. I'd like to hear schemers opinions on this, does the new "big scheme" really address the issue of fragmentation?
The new standard will help marginally, but there will be no grand unification of Schemes. R6RS was big enough for your needs but did not achieve wide adoption. There is no fundamental reason why this would be different for the larger R7RS report (on which work has not yet begun). Indeed, some implementations have already forked with an explicit intention of going on their own paths (Racket).
In short, for serious work, you might be able to share modules between implementations if that matters to you, but your overall application will be implementation-specific.
FWIW, IMHO, etc...
Racket takes an interesting approach with its scoped dialects. This allows the semblance (and some of the semantics) of separate implementations, while still preserving the interoperability[1].
[1] I have one project which uses libraries written in the base, typed, and lazy dialects all together, without any issue.
Which, because I never learned anything about Lisps in school, was that I just wanted to become familiar with it. I looked hard at CL and, when it looked straight back at me and I felt it's ancient, powerful gaze upon me, I quickly ran off to schemeland. Where, of course, I hit the multi-implementations-wall immediately. I didn't want to learn a "toy" (as in "here, have a language - now go and implement all the libraries you need from scratch or by wrapping C calls") language and I wanted to solve real-world problems with my first Lisp, so I naturally looked for "the best" implementation: most library rich, best documented and actively developed and used.
I chose Racket and I'm very happy I did. Not only I learned about Lisp beauty and power while building small, but useful and fun things, I ended up in an environment that makes me improve my skills every time I go back to the language and probably will continue to do so in the future - even when I will finally learn all of the base (not racket/base - racket) language I will just transition smoothly to learning other languages and then to creating my own.
As an effect I don't know Scheme at all, which is makes me feel like I missed something. I know and use several SRFIs, but only when Racket does not provide alternatives, which happens rarely. I have no idea what is written in R6RS and I don't follow R7RS. Heck, I probably don't even know what Scheme is all about! On the other hand, though, I now know (somewhat) a Lisp and a powerful, batteries included, practical language and an experimental academic beast in one.
Anyway, don't use Racket if what you want is just a Scheme. [EDIT: or for embedding. Or producing native binaries (if I understand correctly 'raco exe' mentioned in the article works like py2exe rather than like "real" native compilation... I can be wrong, never used it). Or for anything that Racket is not suitable for ;), but] for everything else I can only recommend it.
(Don't mention Clojure in response to this comment, please. I'm somewhat allergic to it, it's not Clojure fault, it's mine, Clojure is good, really brilliant, very interesting. I'd like to like it, but I don't, sorry... So no, don't ask me 'have I tried Clojure' :) )
[1] http://www.ccs.neu.edu/home/matthias/Thoughts/Racket_is____....
If I remember correctly breaking with this image was one of the reasons for name switch, but it was done rather recently (in 2010) and it will take some more time before Racket will get it's chance in the real world... Just how many years it took Haskell to convince people that it's something more than an obscure research project?
Certainly, the language would benefit greatly from much higher number of libraries, for example, and their lack can be a serious setback for larger projects. On the other hand the language itself includes many sophisticated, impressive features that help with programming such projects - one tiny example is a very nice module system, closer in essence (I think) to that of OCaml than to that of Python and another is an object system, which is well thought out, easy to use and really powerful.
So, while Racket is nowhere near Common Lisp (I really hope you used 'CL' as abbreviation for Common List and not Clojure :)) in industrial usage, I believe that it is (or will be shortly) ready for it's chance in the real world. It would take one or two moderately successful startups to build their products in Racket and open-source all the libraries they wrote to make Racket really viable alternative for other languages.
There is also Bigloo, which is mature and stable implementation.
Scheme48 is an implementation from guys who wrote T, and edited R5RS.
And of course Gambit-C, which is a product of an extraordinary person.)
Right now, I've played with husk-scheme quite a bit, and I like its interface from the Haskell side, but I don't have a lot of confidence in its standards-conformance.