[R6RS] Goals

Michael Sperber sperber
Tue Jan 27 17:51:51 EST 2004


Here's from the list of goals I wrote for the first draft of the
charter.  I still stand by that list:

 8. allow the programmer to write and distribute substantial and
    useful parts of programs so that others can incorporate them into
    their own in unchanged or modified form.

 9. allow the programmer to write substantial and useful programs
    which make use of code written by others (see item #8) and
    distribute them to others say that they may run those programs
    under a variety of Scheme implementations.

 10. allow educators to use the language to teach programming
     effectively, at various levels, and with a variety of didactic
     approaches.

 11. allow educators and researchers to use the language to explain
     and experiment with programming language semantics.

Here are, in my view, the most immediate implications of these goals
for R6RS (in roughly decreasing order of importance):

a) All these goals require a large degree of control over what the
   global names used in piece of Scheme code mean.  In particular,
   this is necessary to assemble programs from parts, to restrict the
   language available to beginners, and to clearly talk about
   restricted subsets.  The blanket name for mechanisms to support
   these things is "module system."  Moreover, for these reasons, I
   believe this includes both value and syntax bindings.

b) R5RS poses a number of problems to writers of portable code.  The
   most important ones are (again, in decreasing order of importance):

   - inexact arithmetic is underspecified
   - EQV? and EQ? are underspecified, most seriously in the area of
     characters
   - the character sets for strings and programs are underspecified
   - most implementations allow continuations created by BEGIN to
     accept any number of arguments; many programs make use of this
   - argument evaluation order is underspecified

   So my goal here is to solve these problems by extending the
   specification.
 
c) Assembling programs from parts requires communication about
   exceptional situations: about the fact that one happened, as well
   as its nature.

d) Substantial and useful programs often need to perform I/O on files
   and other data streams.  R5RS doesn't really provide sufficient I/O
   facilities to do this.  (Note that this problem probably isn't
   solved by simply adding "binary I/O"---I/O needs to be redone.)

e) If Scheme is to be a superior tool for experimenting with language
   semantics, two goals must be met:

   - the language itself must be powerful enough to express a wide
     variety of concepts in programming language semantics
   - the semantics of Scheme itself should be explainable in simple
     terms

   This seems to imply a separation into a core language and
   explicitly named extensions.  (I also think it implies fixing the
   semantics of internal defines to conform to the top level.)

I have also indicated a list of issues that I think are very easily
addressed (because many implementations already agree on them) in a
separate email in the "Common Scheme" thread.  There are more issues
I'd like to ultimately address with R6RS, but these are the most
important ones.

-- 
Cheers =8-} Mike
Friede, V?lkerverst?ndigung und ?berhaupt blabla


More information about the R6RS mailing list