[R6RS] Position on list of issues

[Richard Kelsey]

Here is my (current) stance on these.  I left out the ones
that I have no strong opinion on.
                                            -Richard

> ================================================================
> DELETIONS from R5RS
> 
> - remove transcript-{on,off}

Yes.

> - remove FORCE and DELAY

No.

> - remove multiple values

No.

> ================================================================
> INCOMPATIBLE CHANGES to R5RS
> 
> - make syntax case-sensitive

No.

> ================================================================
> EXTENSIONS that would break implementation-specific extensions
> 
> - specify evaluation order

Torn.  It would help make code portable but there are implementations
out there that might be hard to change.  On this one I feel strongly
both ways.

> - support for processes
> - support for network programming
> - object-oriented programming
> - external representation for records
> - serialization

These all need to be (successful) SRFIs first.

> ================================================================
> EXTENSIONS to R5RS (controversial and probably unnecessary)
> 
> - pattern matching / destructuring
> - abstract data type for continuations
> - support composable continuations
> - add box types

More needed SRFIs.

> - optional and keyword arguments as in DSSSL

Not in plain LAMBDA.  Their could be other LAMBDA-...

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

Yes.

> - records

Yes.

> - Unicode support

Maybe.  We should at least adjust the language to make
it more compatible with unicode.

> - errors and exceptions

Maybe.  I am not sure that anyone knows what the right
thing to do is.

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

Yes, depending on the details of which errors are included.

> ================================================================
> EXTENSIONS to R5RS (probably not terribly controversial)
> 
> - multiline comments

Yes.

> - external representation for circular structures

Yes, although I am not sure if WRITE should produce such
a representation by default.

> - #!eof

Yes.

> - more escape characters

Yes.

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

Yes.

> - 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)

Yes.

> - tighten up specification of inexact arithmetic

Maybe, depending on what is meant.  I would definitely like to
make it easier to avoid silent coercions from exacts to inexacts.

> - add bitwise operations on exact integers

Yes.

> ================================================================
> EDITORIAL CHANGES
> 
> - split language into core and libraries

Yes.