
An opinionated guide to Scheme implementations (2013) - felipebueno
http://wingolog.org/archives/2013/01/07/an-opinionated-guide-to-scheme-implementations
======
davexunit
This is a really great little guide for people that want to try out a Scheme
but are paralyzed by the options. This will help those in need find a starting
point. I highly recommend GNU Guile, the implementation that the author co-
maintains.

~~~
a8da6b0c91d
Guile and its entire library ecosystem is GPL infected. I'd choose to pay the
Chez scheme guy before having to worry about copyleft implications.

~~~
dharmatech
Chez Scheme is not currently available for purchase. This has been the case
since it was aquired by Cicso Systems.

~~~
hga
Yikes! That would explain why the language's site is still Copyright 2011
Cadence Research Systems.

Apparently Cisco bought Cadence, and Chez Scheme fell through the cracks.

Ugh. As far as I know, perhaps not counting the 2 JVM Schemes, it was the only
one that provided OS level non-green threads.

~~~
_delirium
I've never used it myself, but fwiw Gauche also advertises support for native
threads. SRFI-18 threads are wrapped around pthreads on Unixy platforms, and
Windows threads on Windows. [http://practical-scheme.net/gauche/man/gauche-
refe_106.html](http://practical-scheme.net/gauche/man/gauche-refe_106.html)

~~~
hga
Ah, I was not clear enough: native SMP threads, as in each thread accessing
the same shared memory heap. Gauche allocates a new VM for each thread ... ah,
but I see it has data synchronization primitives. I believe it has moved
forward since the last time I checked it, years ago.

Thanks for the tip!

Repeated from the other reply on Guile: Hmmm, now I'll have to narrow the
statement to "The only native code compiling Scheme that I know of" (which is
harder to do).

------
fspeech
What about implementing your own Scheme or Lisp if you want to embed an
interpreter for your C/C++ project (the first scenario discussed in the blog)?
I recently decided to roll my own Prolog interpreter for my project. With
C++11 and shared pointers it is really a breeze (of course I've thought about
doing this for a long time so the actual implementation part was smooth
sailing but not the only story). The advantage of rolling my own:

1\. No GC. Ref counting is sufficient for my own use.

2\. Integrating with the C/C++ libraries I want to use is a lot easier. I
designed my implementation for the purpose of embedding in my project and
gluing libraries.

~~~
username223
> What about implementing your own Scheme or Lisp if you want to embed an
> interpreter for your C/C++ project (the first scenario discussed in the
> blog)?

I've done this for a Java project many years ago, where it sort of grew out of
a config file format, as so many Lisps do. I would probably take the trouble
to add a standard embeddable interpreter if I did it again. Otherwise, you end
up with yet another 80%-ass Scheme with its own quirks and no libraries, and
the world has too many of those already.

~~~
fspeech
"no libraries"

I forgot to emphasize that this is not a real problem. You will likely have
good C/C++ libraries for most things. The real issue really is to expose these
libraries to your embedded language on a as-needed basis. To me the effort is
better spent in creating my own targeted solution that makes interfacing
easier and that is under my control than learning the minutia of the FFI of a
third party implementation, after taking into account the following:

1) we are talking about effort on the scale of one or a few KLOC to roll one's
own, and comparing that against the effort needed to truly master the FFI of a
third party implementation;

2) my interface is no longer limited to the lowest denominator that a standard
implementer would face (e.g. most use C but I can use multiple inheritance and
templates of C++ to make the interfacing a lot easier);

3) supporting FFI users is typically not the highest priority on the standard
implementers' agenda (if there is any support at all).

~~~
username223
> You will likely have good C/C++ libraries for most things.

For most things in your domain. Then someone wants regexps, or Windows path
handling, or what-not, and you find that you didn't really implement Scheme
macros, or some particular style of modules, so you lose.

I agree that if you want C++ integration, you're probably going to want to
roll your own. The first person to write an easy FFI that groks C++ name
mangling will do a tremendous service to mankind.

~~~
astrobe_
There's no "someone" in this context, because you're not designing a language
for the masses, you're making your personal language. At best, if you put it
on Github you'll maybe find a bunch of people wanting the exact same thing so
you'll have a bunch of users&co-implementors that know that they're basically
on their own if they choose to use your language. This is where small and
simple languages such as Scheme, Forth or Lua shine: you can master and hack
everything from the first byte to the last.

The real issue with this approach is that, if you need a particular library
you have to do the bindings yourself first. You have to deal with the delay
required to design, implement and test it. On the other hand, the difference
between learning the API for an another popular language and learning the
native API so you can make the bindings for your language tends to zero as the
complexity and size of said library goes up.

------
leoc
I would hesitate to call DrRacket "excellent".

~~~
thirteenfingers
What specifically are your reservations? - I haven't played around with many
Scheme implementations besides DrScheme/DrRacket so I'm not questioning your
judgement, I'm just genuinely curious.

~~~
ANTSANTS
To expand a bit on "bloat," DrRacket does use a lot of memory for a text
editor (don't have it installed ATM but I remember 100s of megabytes of memory
in use in a typical light session of 1 file + 1 REPL), crashes somewhat
frequently (a couple times in my test run, usually when trying out some of the
crazier features hidden in the menus), and becomes less than responsive due to
_very_ frequent GC pauses (that are helpfully indicated by a little recycling
icon in the corner of the window).

I still think it's a far superior way to introduce newbies to Scheme than
emacs, but it's definitely flawed.

~~~
spdegabrielle
It comes with 'batteries included', and the defaults work fine on most modern
machines.

If you are really resource constrained it's easy to go to the settings and
restrict memory use, and turn off tools you don't intend to use. If you have a
really slow machine there is even a minimal DrRacket.

~~~
ANTSANTS
My Ivy Bridge i7 with 16 gigs of RAM is not exactly resource constrained. I'll
take your word for it that you can disable features to get the resource usage
down, but it's kinda sad that the default config can't run without stuttering
on a machine like that, especially since the program is intended to be used in
_education_ where the average machine is _significantly_ less powerful than
that.

