[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