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.
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.
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.
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:
guardsyntax correct with respect to the dynamic environment? I do not know the answer.
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.
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
receive (as defined by the SRFI) and
receive-and-return (as defined by Vicare); more utilities to write
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
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.
They are diverging. This is how I see it.
comp.lang.scheme. Us and them.
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.
nearly a desert.
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
ciao” error according to R6RS, because the
ciao in the expansion of the
doit use must be renamed
to some hidden identifier. It correctly fails under Vicare, it just works under
#!r6rs (import (rnrs)) (define-syntax doit (syntax-rules () ((_) (define (ciao) (display 123) (newline) (flush-output-port (current-output-port)))))) (doit) (ciao)
This breaks hygiene, because it is not possible to create hidden definitions in the
output forms of macros without explicitly using
The following program is perfectly valid R6RS code and it
123\n under Vicare; under Sagittarius it raises an error.
#!r6rs (import (rnrs)) (define (fun) (mac)) (fun) (define-syntax mac (syntax-rules () ((_) (begin (display 123) (newline) (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.