On choosing an implementation

See your-first-implementation.

Other implementation lists


Implementations active since at least 2020

Compiles to C, JVM and .NET.


A very fast cross-platform native code compiler and a smaller but compatible interpreter.


A very small library intended for use as an extension and scripting language in C programs.


Compiles to C. Good FFI? and large ecosystem.


Compiles to C. Allows practical application development using R7RS Scheme. Focuses on concurrency.


Compiles to C (primarily), Javascript, Python, and others. Focus on performance and stability.


This wiki runs on it. A scripting language scheme interpreter with good Unicode support.


The GNU Scheme interpreter, designed to have good integration with C programs. A nice extension language.


Dialect based upon Gambit.


R6RS Scheme for the .NET Framework.


Runs on the JVM.


R7RS interpreter written in JavaScript.


A dialect of Scheme. Supports many standards. Built on top of Chez.


Small and portable R5RS implementation. Tightly integrated with SLIB, by the same author.


Mostly compliant with R7RS. Includes an object system based on CLOS, GTK+ bindings, POSIX threads, and other useful facilities.


R6RS interpreter.

No activity on/after 2020

This is not to say these implementations are incomplete/unusable/abandoned. Some are very much complete and can be used or studied.


The SCheme SHell, based on Scheme48. This adds a lot of very interesting facilities for POSIX system interfacing.


Became Racket.


The primary design goal was clarity and good design.


A Scheme based extension language kit.


Is a simple and efficient runtime for many standards.


R4RS Scheme, but for Palm Os. Final version from 2008.


Very much dead. Seemingly never released.


Compiles to C. Last release in 2016.

Not sure if still alive

Could anyone check on these?


R6RS Scheme incremental compiler to i32 and i64 native code.


A variant of Scheme48 for distributed computation.


An R5RS Scheme interpreter in OCaml.


A purely functional dialect of R7RS Scheme. Small, embeddable, cross-platform. Has own FFI.


A scheme for WinCE based handhelds.


Compiles to C, has Dylan-like OO features.


A Scheme interpreter in Objective Caml.


A Scheme interpreter in Java, making the whole Java library available to Scheme, and still being very fast (for an interpreter)


The framework for creating web applications using the SISC interpreter.


Is the name for an implementation and dialect of scheme


A lightweight Scheme interpreter


An embeddable C++ implementation


Is this list here really necessary? It is obviously biased heavily towards PLT and provides very little information beyond that. In any case, looking at the links in the Scheme FAQ's list would be much more informative, and it would seem a waste to duplicate the entirety of that list.


I think having the list here on csw is better than just referring readers to the FAQ's list, as here entries can be easily added, adapted, expanded etc. In other words, the whole point of a wiki is that is doesn't tend to go out of date as a static HTML page such as the Scheme FAQ. As to the PLT bias, that is easily corrected, no?


I see this as a category listing: What implementations are mentioned on this wiki at all? As for the PLT bias, I do agree. Please feel free to improve the descriptions of the others, or move the PLT description on the implementation page...


I reworded PLT's descritption so it's less biased. I also added kali to Scheme 48 because I don't think kali should have its own entry.


I would appreciate the list containing some information about exactly what is required for the final runtime: Nothing, you end up with a native executable; vm or interpreter, with wrappers or without; dynamic libraries; other... This is often a critical choice if you aren't just making something that you'll run on the development machine or which warrant massive software installs on some well known platform on a production system somewhere. The final dependencies, if you will. In other words a practical description of the implementation in its use instead of theoretical.


At this point, the implementation list is no longer biased, and is much more usable than the FAQ implementation table (which is pretty useless: it has names and URLs only). Suggestion: either list all implementations here, or expand the implementation table in the FAQ.


I needed to put together a cheap summary list of different scheme implementations for a friend. I can't vouch for its quality/accuracy, but with a little bit of formatting, it might be of use to the right person. I was originally interested in the last update and reason why a developer implemented their version of scheme, but I also included the targets and platform iff they were really easy to find. (pardon the pastebinning of it. I'd feel guilty adding the contents of this to the page. Hopefully someone else will and keep it looking professional. ;) )


Should we remove 'The most comprehensive list of Scheme implementations is in the scheme-faq' since there seems to be no such list on that page? Being the 'most comprehensive' also sounds like a very strong claim.

Should we link internal pages such as your-first-implementation? For newbies that should be more valuable than being comprehensive.

Should we link external pages such as and and which also list implementations?

Should we remove/move defunct implementations such as Stalin from this page?

May I add a section or page on common criteria for choosing an implementation, such as license, portability, standard conformance, compiled/interpreted etc.?


I just added in some newer interesting implementations and tried to separate dead/active implementations. Choosing 2020 as a cutting off point is very arbitrary. I couldnt come up with anything better. Also included external links and internal links for pointings newbies to something more 'tutorial' and less 'reference'.