Internals Gerbil

The main meta-language in which we are implementing Glow is Gerbil Scheme.

Gerbil Scheme is a great development environment, but it has some caveats that you need to be aware of.

A Language in Many Layers

• The base language for Gerbil is Scheme, a simple yet powerful language designed to make metaprogramming easy, based on dynamically typed functional programming core, extended with effects such as mutation or first-class continuations.

• Gerbil's runtime is based on Gambit Scheme, a very robust and portable implementation of Scheme developed over the last 30+ years by Marc Feeley, that can generate very efficient code by compiling to C (and can also compile to JavaScript, PHP, Java, x86 assembly, and more).

• Gerbil has a powerful module system inspired by Racket: it allows you to organize your code in very flexible ways; it makes metaprogramming in modular, and even helps you define your own languages as part of a common environment.

• Gerbil comes "batteries included" with a rich standard library, that covers most of your every day needs for concurrency, networking, cryptography, system access, data structures, iteration, an object system, an actor system, and much more.

• We have been developing our libraries on top of Gerbil as part of a budding ecosystem.

Main Caveat: Documentation

The main issue with adopting Gerbil currently is the lack of a one-stop-shop for documentation.

Often, using apropos at the REPL will help you locate the function you need. It is also helpful to have the sources for Gambit, Gerbil and your libraries, so you can use git grep to locate the functionality. And of course, you should not hesitate to ask for help on our Discord #help channel.

Once you have located the functionality you need, you may currently have to consult some varying reference material to fully understand its semantics:

• For basic language semantics, you'll want to look at the R5RS Scheme standard.

• For elementary data structures (arrays, bytes, byte arrays, etc.), and elementary I/O services (file access, paths, threads, etc.), you'll want to look at the Gambit documentation.

• For some standard extensions to Scheme, you'll want to look at the SRFI documentation. Note that some SRFIs are builtin to Gerbil (such as SRFI 26 for the cut macro that is colloquial in Gerbil), while others can be loaded from the Gerbil standard library (such as SRFI 1 for common list functions, or SRFI 13 for common string functions). Some might not be available in Gerbil (yet).

• For some features specific to Gerbil, and for the Gerbil standard library, you'll want to look at the Gerbil documentation itself.

• For features specific to Gambit, you can look at Gambit's reference.

• For features in our libraries, often the best we have is comments in our source code.

• A few advanced features (notably the syntax-case the macro system) are only fully explained in the academic literature that describes those features and their extensions.

• And then there are plenty of underdocumented or wholly undocumented features in Gambit, Gerbil or our libraries.

Fixing this documentation situation should be a priority if there were serious funding for Gerbil Scheme. Ideally, we'd have a searchable site like Racket's.

If you are familiar with programming and what to learn the Scheme language, you might enjoy The Scheme Programming Language. But mind that it is based on Chez Scheme, which differs from both Gerbil and Gambit, so any time you stray from the core language, the details may be quite different.

Extending the Library Ecosystem

In addition to the functionality builtin to Gerbil, there is a growing collection of packages with Gerbil libraries. When the functionality you are looking for isn't available yet, there are many options or increasing cost:

• Libraries written in standard or somewhat portable Scheme can be trivially wrapped.

• Libraries written for Gambit Scheme can also be trivially wrapped.

• Libraries designed for some different Scheme dialect are usually easy to port to Gerbil Scheme.

• Libraries written for Racket or Common Lisp are also often simple to port.

• C libraries or libraries that expose a C API can easily be accessed from Gambit Scheme using its straightforward FFI. One downside is that if you don't use the C backend of Gambit Scheme, but e.g. the JavaScript backend (that we are considering using at some point), then you'll need a different FFI to a different set of libraries that are native to the target platform, and maybe some conditional compilation to make things work in both contexts.

• Libraries written in about any language are usually quite easy to translate to Gerbil Scheme, since Gerbil Scheme is such a very expressive language.

• Libraries using unusual advanced features of some languages, such as logic programming or type-level programming, may require that you first build the necessary infrastructure in Gerbil Scheme, or (im)port from some library as above. That's always possible, but sometimes not worth the hassle, or not yet. For instance, we notably haven't ported Racket's syntax-parse, that we might want to have to port some Racket libraries that use it.

• When the library being ported relies on type-level programming at compile-time, we often instead translate to regular programming at runtime, since we don't (currently) have a specific type-level programming phase. For instance, we typically translate Haskell typeclasses to using a prototype as an extra explicit argument where Haskell would translate the typeclass into an extra implicit dictionary argument when translating to Haskell Core. If we really wanted the computation at compile-time, we'd use macros; but then we might eventually end up having to reimplement types in the macro system, if we want the computation to be based on type inference.