If you have time, I'd be curious for your reasons not to use Prolog to implement scheme. I've been playing with Prolog lately and to my newbie eyes it seems like it would be a good host language for interpreters.
My email is in my profile if you'd rather email me directly rather than dumping something controversial here.
It was a long time ago, and I was a newbie as well, but I just remember it being one of the more painful things I've done. Coming from C, I remember it being a mix of amazing easy and amazingly hard. Things that would be 100s of lines of C were one or two lines of Prolog. But sometimes figuring out those few lines and debugging them was a huge pain. I still find Prolog hard to follow, you can't just read it in order like imperative languages.
This is part of the reason I dislike scheme. Too many incompatible implementations. I'm a die hard common lisp fan, and I love the fact that cl has many implementations and that any software I write will run on most or all of them unchanged. With scheme, any interesting software pretty much has to be written for a particular implementation, because scheme is simply too small.
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?
Sounds like your problem is more that Scheme is too small for the programs you'd like to write. Implementations that are adequate to your needs being incompatible with each other is a natural side effect.
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.
> Indeed, some implementations have already forked with an explicit intention of going on their own paths (Racket).
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.
It's true and really noteworthy - Racket is in large part a toolbox for language creation and framework for those languages interoperability[1]. It's one of the reasons I chose to stay with Racket after fulfilling my initial goal.
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' :) )
It's true... I didn't search very hard, but I didn't find any "real world and/or big" apps written in Racket. [Edit: of course if we exclude Hacker News website, which is written in Arc, which is in turn written in Racket.] I think it's mainly because it is (or was) a Scheme - language almost universally thought to be very beautiful, very useful in education and completely useless in real world.
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.
One thing that I would add is that Chibi Scheme is trying to be compatible with the R7RS-Small specification (for those of you interested in working on the bleeding edge).
I believe the main developer of Bigloo has always been Manuel Serrano [1]. I'm not 100% sure, but I think so. I think he is more focused on Hop [2] than Bigloo nowadays.
Any good implementations of Scheme that take the minimalist approach, implementing only RNRS for some sensible value of N? For my purposes, I need a version of Scheme for which the language implementation (as opposed to the libraries) will remain unchanged for a very long time.
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.
i think it's kind of disingenuous to gloss over the fact that guile doesn't work on windows. nothing against it; it's a beautiful scheme implementation, and it's fine that they don't want to support windows, but the article should say explicitly "note: does not play well with windows" rather than simply "binary packages are available on all Free Software systems".
https://github.com/FigBug/scheme