
An opinionated guide to Scheme implementations - p4bl0
http://wingolog.org/archives/2013/01/07/an-opinionated-guide-to-scheme-implementations
======
FigBug
A while back I wrote a Scheme interpreter in Prolog. I would recommend nobody
use it. Nor would I recommend writing Scheme in Prolog.

<https://github.com/FigBug/scheme>

~~~
sea6ear
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.

~~~
zura
You might find interesting to read:

"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...](http://www.amazon.com/Formal-Syntax-Semantics-Programming-
Languages/dp/0201656973)

the implementations are in Prolog.

~~~
sea6ear
Thanks for the links, I'll take a look at that.

------
pavelludiq
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?

~~~
wingo
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.

FWIW, IMHO, etc...

~~~
chimeracoder
> 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.

~~~
klibertp
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' :) )

[1]
[http://www.ccs.neu.edu/home/matthias/Thoughts/Racket_is____....](http://www.ccs.neu.edu/home/matthias/Thoughts/Racket_is____.html)

~~~
sw2wolf
But few real world app. is developed using racket compared with CL ?

~~~
klibertp
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.

------
inetsee
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).

------
dschiptsov
SCM with Slib is good to _read_.

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.)

~~~
dman
Bigloo is also a product of an extraordinary person. From what I can tell its
largely written by Christian Queinnec.

~~~
p4bl0
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.

[1] <http://www-sop.inria.fr/members/Manuel.Serrano/>

[2] <http://hop.inria.fr/>

~~~
dman
Sorry, I was wrong, I stand corrected.

------
bhickey
Why would you prefer Chibi Scheme to Guile for embedding as a scripting
language?

~~~
batgaijin
hell of a lot smaller.

------
JoshTriplett
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.

~~~
nils-m-holm
The Scheme 9 from Empty Space core has been stable for a very long time, and I
do not plan any major changes. See <http://t3x.org/s9fes/>

------
zem
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".

~~~
qznc
Does it work on OS X?

~~~
zem
i've only used it on linux, but as far as i know it should build easily enough
on osx, seeing as how it's unixy under the hood.

