[R6RS] categorization of goals (rationale)

[William D Clinger]

My purpose in this message is to explain why I placed certain
selected issues into one of the following categories:

    deletions of R5RS Scheme features
    incompatible changes to R5RS Scheme
    extensions that could be entirely compatible with R5RS Scheme
        but would break some implementation-specific extensions
        but would be controversial and aren't worth it

I will also offer some opinions on what we should do about some
of these issues, even though we're not supposed to be having a
technical discussion yet.

Will

================================================================
DELETIONS from R5RS

- remove FORCE and DELAY

I think the main argument for keeping these in R6RS is that they
are really hard to implement correctly.  They don't belong in
the core, but they'll be reimplemented badly if we don't put
them into a standard library.

- remove multiple values

I don't see the point of removing these.  Multiple values have
demonstrated their worth in several implementations, including
at least Chez Scheme, Larceny, and PLT Scheme.  What advantage
would accrue from removing them?

================================================================
INCOMPATIBLE CHANGES to R5RS

- make syntax case-sensitive

This would break at least some real code.  If the perceived need
for case-sensitive identifiers is to communicate with other
languages, then let's invent some lexical syntax such as
{hashCode} or |hashCode| that allows programmers to write
case-sensitive identifiers.  That wouldn't break any R5RS code.

================================================================
EXTENSIONS that would break implementation-specific extensions

- specify evaluation order

www.schemers.org lists 60 implementations of Scheme.  Some of
these implementations have defined an implementation-specific
order of evaluation, and have told their users they can rely
on this order of evaluation.  No matter what order we choose---
if we can even agree on one among ourselves, which I doubt---
it will break code that was written to rely upon other orders
of evaluation.

- support for processes

Here we have the same issue as with evaluation order, and we
also have the fact that a process semantics that makes sense
for many architectures and OSs isn't going to make sense for
all.  Support for processes may belong in standard libraries,
but that support should not be required of all R6RS-conforming
implementations.

- support for network programming

IMO this is more appropriate for standardization than processes,
and belongs in a standard library, but should not be required of
all implementations.

- object-oriented programming

There are many incompatible extensions for object-oriented
programming.  We can't standardize here without breaking a lot
of implementation-specific code.  If there were a clear winner
among the OO extensions, it would be one thing, but I don't see
a clear consensus at this time.

- external representation for records

Again, there are several incompatible implementation-specific
extensions for this.  It might be worthwhile to break them,
since whatever we decide to do for records is going to break
some implementation-specific extensions anyway.

- serialization

This is a generalization of the issue for records, I think.  I'm
not convinced serialization is worth standardizing, but I doubt
whether too many systems have implementation-specific extensions
for serializing general objects.

================================================================
EXTENSIONS to R5RS (controversial and probably unnecessary)

- pattern matching / destructuring

Mainly I don't want to put this sort of thing in the core
language.

- abstract data type for continuations

For years I've been pointing out that a procedure that takes one
argument and passes it to a captured continuation is equivalent
to that continuation, and I don't see the point of creating any
artificial distinctions between the two...

- support composable continuations

...unless they are necessary to support composable continuations,
and we decide to take that leap.  My mind is open on this.

- add box types

This just isn't very important.

- uninterned symbols
  vs. Chez's globally unique names

My mind is open on this.  We may need something like Chez's
globally unique names for the record system.

- extended symbol syntax

I'd prefer to simplify the symbol syntax.  I gag on any syntax
that allows a program's identifiers to contain whitespace.

- add LETREC*, define internal DEFINE in terms of it

My mind is open on this, but I will offer some arguments against
doing this when we get around to technical discussions.

- optional and keyword arguments as in DSSSL

CASE-LAMBDA is better than optional arguments, and keyword
arguments should be banished to some KEYWORD-LAMBDA macro.

================================================================