[R6RS] categorization of goals

[R. Kent Dybvig]

> DELETIONS from R5RS

> - remove transcript-{on,off}

No objection.

> - remove FORCE and DELAY

I agree with Will that these should be in a standard library.

> - remove multiple values

I believe that they should remain and that we should in fact add
let-values from SRFI 11.

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

> - make syntax case-sensitive

I wouldn't mind breaking some existing code to make symbols case
sensitive.  My reasons have only to do with expanding the namespace.
For example, I find it really useful to write, e.g., Expr for the
procedure that handles exprs, and use expr as the name of Expr's argument.

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

> - specify evaluation order

I don't mind specifying that internal defines are ordered from left to
right, but I object to specifying the order in which the subexpressions of
an application or right-hand sides of let and letrec are evaluated.  The
unspecified order gives the programmer a way to express that evaluation
order is unimportant, and we'd lose that entirely.  Said another way,
a fixed evaluation order forces overspecification.

I've considered the argument that it's easier to prove programs correct
or to portably test programs if the evaluation order is specified, but
a simple way around that is to first transform the program to make the
order explicit, then prove or test the program, and draw conclusions
only about the transformed program.

> - support for processes

Pthreads is fairly ubiquitous these days, so it might be useful to have
a standard thread system based on pthreads.  This is probably better as
an SRFI in the short term, however.

> - support for network programming

This should go into a standard library.

> - object-oriented programming

This is probably too controversial.

> - external representation for records

This seems like a good idea to me.

> - serialization

No opinion.

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

> - pattern matching / destructuring

No opinion.

> - abstract data type for continuations

This strikes me as similar to the arity? procedure that we've voted
down several times in the past, in that it is useless in the presence
of procedural embeddings.  If an continuation? is false of an object,
does that mean it can't behave like a continuation?

> - support composable continuations

I think it would be nice to standardize on a set of low-level operators
that are strong enough to implement call/cc and the variety of functional
control operators that have been proposed, then relegate call/cc to
library status.  (To be clear: I want to make sure we have support for
continuations in the core.)

> - add box types

I never use boxes myself, so I'd prefer to let them die.  There's not
much advantage to including them once we have records.

> - uninterned symbols
>   vs. Chez's globally unique names

Naturally, I'd like to include globally unique names (which we call
gensyms).

> - extended symbol syntax

This goes along with gensyms.

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

I don't care about adding letrec*, but specifying that definitions be
evaluated left to right might be useful.

> - optional and keyword arguments as in DSSSL

I prefer case-lambda.  Optional and keyword arguments can be handled in
a library.

> ================================================================
> EXTENSIONS to R5RS (controversial or difficult but necessary)

> - module system

I favor both Dr. Scheme's notion of modules, which to me are more like
libraries or compilation units, and Chez Scheme's notion of modules,
which are available to control scope at all levels.  I believe that
they are really separate notions.

> - non-hygienic macros

Naturally, I think this is a good idea.

> - records

Yes, both in a procedural and syntactic form.

> - mechanism for new primitive types

Isn't this essentially the same as records?

> - Unicode support

Yes (as part of the core).

> - errors and exceptions

Yes.

> - require mode where "it is an error" means "an error is signalled"

Yes.

> ================================================================
> EXTENSIONS to R5RS (probably not terribly controversial)

> - multiline comments

Yes.  Plus #;<s-expr> to comment out s-expressions.  This came up at
some point but didn't make this list.

> - external representation for circular structures

Yes.

> - #!eof

Yes.

> - more escape characters

Yes.

> - require that #f, #t, and characters be followed by a delimiter

Yes.

> - CASE-LAMBDA

Yes.

> - add COND-EXPAND

Is this something like eval-when?  We've worked out eval-when so that
it is really quite sensible (and useful), but I sense strong opposition
to it.  I don't think the Dr. Scheme notion of module completely covers
what eval-when can do, but I'd be happy to be proven wrong.

> - allow the name of the macro being defined in SYNTAX-RULES to be
>   arbitrary (or _)

Yes.

> - allow continuations created by begin to accept any number of values

Yes.

> - tighten up specification of EQ? and EQV? (or otherwise address their
>   portability problems)

No opinion.

> - tighten up specification of inexact arithmetic

Yes.

> - add +0, -0, +inf, -inf, +nan

Yes, but with slightly different syntax.  +0 and -0 are already both
exact 0, and I wouldn't want to change that.  IEEE -0.0 would presumably
have to be written as -0.0 (or -0e20 or -0###, etc.).  I also favor
+inf.0, -inf.0, and +nan.0 since the .0 makes clear that they are inexact
(in case someone someday wants to add exact nan or [hmm...] inf); also,
the .0 makes the numberness jump out better.

This probably goes along with a commitment that inexact numbers are
IEEE floats.

> - add bitwise operations on exact integers

Yes.

> - SRFI 4 homogeneous numeric vectors

No opinion.

> - specify dynamic environment

No opinion.

> - operations on files

Yes.

> - binary I/O
>   or: new I/O subsystem entirely

Unsure.

> - string code

Yes (library).

> - regular expressions

Yes (library).

> - command-line parsing

Yes (library).

> - hash tables

Yes (library).

> - library for dates

Yes (library).

> - system operations

Yes (library).

> ================================================================
> EDITORIAL CHANGES

> - split language into core and libraries

Yes---but I prefer a rather larger core than some might prefer,
probably even larger than the current r5rs.

> ================================================================
> ADDITIONAL EXTENSIONS

- Support for expression comments, as mentioned above.

    (let ((x 3) #;(y 4))
      #;(write (list x #;y))
      (* x x))

  reads as (let ([x 3]) (* x x)).  This also subsumes the common usage of
  ' to comment out top-level forms, which breaks down for non-top-level
  definitions.

- Support for a subset of Common Lisp format (in a library).
  Lack of support for formatted I/O is something that turns lots of
  people off about Scheme.

  (This occurred to me as I worked on this note---sorry for not submitting
  it sooner.)

Kent