3.1.1 Introduction

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. Scheme demonstrates that a very small number of rules for forming expressions, with no restrictions on how they are composed, suffice to form a practical and efficient programming language that is flexible enough to support most of the major programming paradigms in use today.

Scheme was one of the first programming languages to incorporate first–class procedures as in the lambda calculus, thereby proving the usefulness of static scope rules and block structure in a dynamically typed language.

Scheme was the first major dialect of Lisp to distinguish procedures from lambda expressions and symbols, to use a single lexical environment for all variables, and to evaluate the operator position of a procedure call in the same way as an operand position.

By relying entirely on procedure calls to express iteration, Scheme emphasised the fact that tail–recursive procedure calls are essentially gotos that pass arguments.

Scheme was the first widely used programming language to embrace first–class escape procedures, from which all previously known sequential control structures can be synthesised.

A subsequent version of Scheme introduced the concept of exact and inexact number objects, an extension of Common Lisp’s generic arithmetic.

More recently, Scheme became the first programming language to support hygienic macros, which permit the syntax of a block–structured language to be extended in a consistent and reliable manner.

Guiding principles

To help guide the standardisation effort, the R6RS editors have adopted a set of principles, presented below. Like the Scheme language defined in Revised^5 Report on the Algorithmic Language Scheme, the language described in the R6RS report is intended to:

• allow programmers to read each other’s code, and allow development of portable programs that can be executed in any conforming implementation of Scheme;
• derive its power from simplicity, a small number of generally useful core syntactic forms and procedures, and no unnecessary restrictions on how they are composed;
• allow programs to define new procedures and new hygienic syntactic forms;
• support the representation of program source code as data;
• make procedure calls powerful enough to express any form of sequential control, and allow programs to perform non–local control operations without the use of global program transformations;
• allow interesting, purely functional programs to run indefinitely without terminating or running out of memory on finite–memory machines;
• allow educators to use the language to teach programming effectively, at various levels and with a variety of pedagogical approaches;
• allow researchers to use the language to explore the design, implementation, and semantics of programming languages.

In addition, the R6RS report is intended to:

• allow programmers to create and distribute substantial programs and libraries, e.g., implementations of Scheme Requests for Implementation, that run without modification in a variety of Scheme implementations;
• support procedural, syntactic, and data abstraction more fully by allowing programs to define hygiene–bending and hygiene–breaking syntactic abstractions and new unique datatypes along with procedures and hygienic macros in any scope;
• allow programmers to rely on a level of automatic run–time type and bounds checking sufficient to ensure type safety;
• allow implementations to generate efficient code, without requiring programmers to use implementation–specific operators or declarations.

While it was possible to write portable programs in Scheme as described in Revised^5 Report on the Algorithmic Language Scheme, and indeed portable Scheme programs were written prior to the R6RS report, many Scheme programs were not, primarily because of the lack of substantial standardised libraries and the proliferation of implementation–specific language additions.

In general, Scheme should include building blocks that allow a wide variety of libraries to be written, include commonly used user–level features to enhance portability and readability of library and application code, and exclude features that are less commonly used and easily implemented in separate libraries.

The language described in the R6RS report is intended to also be backward compatible with programs written in Scheme as described in Revised^5 Report on the Algorithmic Language Scheme to the extent possible without compromising the above principles and future viability of the language. With respect to future viability, the editors have operated under the assumption that many more Scheme programs will be written in the future than exist in the present, so the future programs are those with which we should be most concerned.