MIT Scheme Reference

Edition 1.62

for Scheme Release 7.4

16 April 1996

by Chris Hanson

the MIT Scheme Team

and a cast of thousands

(1)

MIT Scheme implements the whole tower of numerical types. It has unlimited-precision exact integers and exact rationals. Flonums are used to implement all inexact reals; on machines that support IEEE floating-point arithmetic these are double-precision floating-point numbers.

(2)

MIT Scheme implements all of the written notations for numbers.

(3)

In MIT Scheme the rational? procedure is the same as real?, and the complex? procedure is the same as number?.

(4)

MIT Scheme signals an error of type condition-type:bad-range-argument in this case.

(5)

Some of the details in this section depend on the fact that the underlying operating system uses the ASCII character set. This may change when someone ports MIT Scheme to a non-ASCII operating system.

(6)

Note that the Control bucky bit is different from the ASCII control key. This means that #\SOH (ASCII ctrl-A) is different from #\C-A. In fact, the Control bucky bit is completely orthogonal to the ASCII control key, making possible such characters as #\C-SOH.

(7)

Because character sets are implemented as strings, string? returns #t for character set objects. However, string operations aren't meaningful with character sets.

(8)

The above definitions imply that all lists have finite length and are terminated by the empty list.

(9)

Note that path is restricted to a machine-dependent range, usually the size of a machine word. On many machines, this means that the maximum length of path will be 30 operations (32 bits, less the sign bit and the "end-of-sequence" bit).

(10)

Although they are often used as predicates, memq, memv, and member do not have question marks in their names because they return useful values rather than just #t or #f.

(11)

In older dialects of Lisp, uninterned symbols were fairly important. This was true because symbols were complicated data structures: in addition to having value cells (and sometimes, function cells), these structures contained property lists. Because of this, uninterned symbols were often used merely for their property lists -- sometimes an uninterned symbol used this way was referred to as a disembodied property list. In MIT Scheme, symbols do not have property lists, or any other components besides their names. There is a different data structure similar to disembodied property lists: one-dimensional tables (see section 1D Tables). For these reasons, uninterned symbols are not very useful in MIT Scheme. In fact, their primary purpose is to simplify the generation of unique variable names in programs that generate Scheme code.

(12)

MIT Scheme reserves a specific set of interned symbols for its own use. If you use these reserved symbols it is possible that you could break specific pieces of software that depend on them. The reserved symbols all have names beginning with the characters `#[' and ending with the character `]'; thus none of these symbols can be read by the procedure read and hence are not likely to be used by accident. For example, (intern "#[unnamed-procedure]") produces a reserved symbol.

(13)

In MIT Scheme, the returned list is always newly allocated.

(14)

This introduction is taken from Common Lisp, The Language, second edition, p. 431.

(15)

Although they are often used as predicates, assq, assv, and assoc do not have question marks in their names because they return useful values rather than just #t or #f.

(16)

Because Scheme's escape procedures have unlimited extent, it is possible to escape from the current continuation but later to escape back in. If implementations were permitted to close the port on any escape from the current continuation, then it would be impossible to write portable code using both call-with-current-continuation and call-with-input-file or call-with-output-file.

(17)

The value returned by a call to peek-char is the same as the value that would have been returned by a call to read-char on the same port. The only difference is that the very next call to read-char or peek-char on that input-port will return the value returned by the preceding call to peek-char. In particular, a call to peek-char on an interactive port will hang waiting for input whenever a call to read-char would have hung.

(18)

char-ready? exists to make it possible for a program to accept characters from interactive ports without getting stuck waiting for input. Any input editors associated with such ports must make sure that characters whose existence has been asserted by char-ready? cannot be rubbed out. If char-ready? were to return #f at end of file, a port at end of file would be indistinguishable from an interactive port that has no ready characters.