what should RnRS be all about?

["Gerald Jay Sussman" <gjs@martigny.ai.mit.edu>]

You suggested that one possible alternative is:

      - Declaring RnRS a finished project and disbanding the authors
        committee.

I think that RnRs is not a finished project.  We have a few specific
pieces unfinished business that I think are crucial for the future
viability of Scheme-like languages.

  1. The establishment of a high-quality exception-handling system:
There must be an agreed minimal means of handling errors, such as the
ones that come out of the file system and the ones that come from
arithmetic.

  2. Agreed upon mechanisms to deal with interrupts, multiprogramming,
multiprocessing, and parallelism.  I am being deliberately vague about
the range of concerns here, but I want to emphasize the view that many
of us are trying to build operating-systems/organisms that respond to
environmental events and to internal conditions.  This may show the
relation to concern #1, above.

  3. Some agreed-upon mechanism for coercing code text to executable
code -- as in EVAL (Evil? -- many of us seem to see it that way!).

The problem here is exactly as Bill Rozas suggests.  My process is a
living and evolving organism.  It is only an artifact of our present
primitive development that we reboot machines every day and we restart
Scheme every time we want to fix a major bug.  I must be able to
repair it when broken.  I must be able to augment a running system
with new patches.

I imagine a time when we have processes for which the data developed
during running has taken 20 years to create.  That is why it is a
crime to murder a human.  The data is too valuable to lose by a
cold-boot.  Programmers will have to be physicans.

Sorry to flame, but I really need to get this one off my chest.  I
watch the proceedings of the Scheme business with a bit of detachment,
but I think that many of the arguments are about this distinction.
There are those of us who are designing a language to write neat
programs, and there are those of us who are designing a language for
building critters.  To me there are lots of good languages for the
first purpose, but only the Lisp community has addressed the problem
of the second, and only informally.  MIT Scheme, for example, has a
well-developed exception handler, it has an EVAL, it supports multiple
processes, it has debuggers (we may complain, but it is pretty good).
Other Schemes also have such features.  They must, because the systems
wizards who build them are usually critter people.  We need to agree
about such features, to formalize these powerful and useful notions
that have made us so successful!