Next: , Previous: , Up: 2015   [Contents][Index]

Does the Scheme standard still matter? (2015 February 16)

In the history of the Scheme language there are documents defining the “standard Scheme”: the report, the revised report, R4RS, R5RS, R6RS, R7RS. Vicare is an R6RS implementation. R6RS is hated. Some people say that it must die. I guess that: because some People That Matter hate it, other people just hate it because it is cool to do so; this is pretty normal human behaviour.

Philosophy of Scheme

Usually one refers to this quote, which is included in the introduction of the R6RS document:

Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary.

How beautiful! How useful? As I see it: every general purpose language that tries to be useful becomes complex and, inevitably, features are piled up. But this philosophy has actually succeeded in defining concepts that are both instruments of thought and instruments of language implementation: closures, continuations, proper tail–call optimisation, the dynamic environment.

Every high–level construct in every Scheme implementation can be described by a composition of core language constructs and, indeed, some implementations actually transform the high–level language source code into core language forms that are compiled or interpreted. Some implementations define a core language that is actually pretty human–readable Scheme code.

Success! The philosophy is established and acknowledged. Let’s not sweat it anymore.

NOTE I have noticed only today that, while adapting the text of the R6RS documents for Vicare’s documentation, I cut out the paragraphs describing the report philosophy. I fixed this, they are included now.

Scheme implementations and R6RS

There are so many Scheme implementations that I have no will to list them, just get this (which does not list Vicare, he! he!) and this and this. Of the implementations supporting R6RS, listed on the report’s site:


It is far from being a full implementation. There are no hygienic macros.

Chez Scheme

It has gone West.


It is not a full implementation; its web page claims to offer only partial support. In version 2.0.11 the expander has some incompatibilities (the same problem of Sagittarius described below and more10).


It has gone West. Vicare is a fork of Ikarus.


It is still alive. I do not know it. It appears full continuations are not implemented and will never be. This is a limitation from my point of view:


There has not been a release in years. I do not know what this means.


There has not been a commit to the repository in years. In my humble opinion: it is to be considered gone West.


It implements R6RS through the executable plt-r6rs and (most likely) some other way of selecting the language. Racket’s people have rightfully gone their way, defining their own language, for their own purposes. I think it is fair to assume we should not rely on Racket’s implementation of R6RS, it is just legacy code for them.


It is still alive. The expander has problems, with respect to R6RS compliance11.


It has gone West.

Everything is all right: people move on. Concretely, for my purposes, the only R6RS implementation is Vicare.

Unanswered questions on the usefulness of R7RS

Every now and then I ask myself if it would be worth it to support R7RS under Vicare. One thing I am sure of is that: it would be more work; with the already long queue of things–to–do for Vicare: I have no will.

Both R5RS and R7RS define “small” languages; they have differences. I wonder what more R7RS truly has to offer over R5RS. When I skimmed over the R7RS report: nothing jumped into my eyes. Sure it has library forms and cond-expand is integrated in the language; these are very useful to write portable code. There is support for exceptions; good. So what?

The R7RS of my dreams is bigger than R6RS and backwards compatible. More syntaxes like receive (as defined by the SRFI) and receive-and-return (as defined by Vicare); more utilities to write macros, like syntax/loc as defined by Racket; a universal interface for garbage collector finalisers; an unwind–protection mechanism that is as reliable as possible; non–blocking input/output ports; more standard libraries for coroutines, containers, networking, foreign–functions interface, file systems; an API for POSIX services.

The R7RS “small language” looks useless to me; is it only a convenient base on top of which to implement the future R7RS “big language”? So will I have to wait until the big language takes shape to build an opinion?

I am a mediocre programmer; nevertheless, R6RS allowed me to search, resurrect, adapt, document and test a fair amount of libraries in R6RS format. I treasured the work of other people. R7RS is backwards incompatible: this is like being hard tackled.

Scheme users communities

They are diverging. This is how I see it.

These communities form a non–community of Scheme users. Maybe I am not reading in the right places (or I am not stalking enough people to know what they are actually doing) but I do not perceive significant interaction. comp.lang.scheme is nearly a desert.

Is the Scheme standard still important?

If a standard does not aggregate the work of people, establishing a platform over which to build new stuff: it is irrelevant.



The following program must raise an “unbound identifier ciao” error according to R6RS, because the definition of ciao in the expansion of the doit use must be renamed to some hidden identifier. It correctly fails under Vicare, it just works under Guile.

(import (rnrs))
(define-syntax doit
  (syntax-rules ()
     (define (ciao)
       (display 123)
       (flush-output-port (current-output-port))))))

This breaks hygiene, because it is not possible to create hidden definitions in the output forms of macros without explicitly using with-syntax and generate-temporaries.


The following program is perfectly valid R6RS code and it prints 123\n under Vicare; under Sagittarius it raises an error.

(import (rnrs))
(define (fun)
(define-syntax mac
  (syntax-rules ()
       (display 123)
       (flush-output-port (current-output-port))))))

Notice that the macro mac is defined after its use in the body of fun; this is no problem according to R6RS and it allows organising code without restrictions on the order of definitions. Very useful and, indeed, I use it all the time in my code, which does not run under Sagittarius.

Next: , Previous: , Up: 2015   [Contents][Index]