[R6RS] Records draft

[dyb at cs.indiana.edu]

> My first impression (more to follow) is that the syntax of the  
> syntactic record definition form suffers from a bad case of  
> parenthesitis.  It is just too verbose and has too many positional  
> arguments that will be hard to remember.

We wanted to maximimze in parallel the following three things:

  * use of explicit names (layer 0 interface)
  * use of implicit names (layer 1 interface)
  * cross-compatibility of both of the above

By cross-compatibility, we mean

  - easily switching from implicit to explicit names
  - easily switching from explicit to implicit names
  - combining explicit and implicit names, i.e., explicitly overriding
    just some of the implicit names

We also had an orthogonal goal, which is to allow enough control
over the creation routine (maker) so that one would rarely need to
define a separate maker in terms of the automatically generated one.
In particular, we wanted to address, in a general manner, the common
situation where some fields are not directly initialized by the code that
calls the instance maker.  This might be, for example, an immutable field
that is initialized by some non-trivial function of the maker arguments,
such as a hash table's "hasher" field whose value is based on the maker's
"predicate" argument.  It might also be a field that is initialized
to some constant value and later altered, such as a variable record's
"mutable" field that is initially false and may be set to true during
syntactic analysis.

The rather verbose syntax we came up with addresses all of these goals.
The downside is that it is rather verbose, since it involves more
parentheses and keywords than a more minimalist approach that does not
satisify these goals.  In particular, there's a lot for the programmer
specify in the "layer 0" (explicit names) interface, where constructor,
predicate, accessor, and setter names are specified explicitly.  We can
reduce the number of parentheses and positional items with more keywords
(or visa versa), but the interface we proposed seems to us to strike
the right balance.

Kent