[R6RS] categorization of goals

Matthew Flatt mflatt
Wed Mar 10 08:23:03 EST 2004


Basic opinions...

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

In favor.

> - remove FORCE and DELAY

Neutral.

> - remove multiple values

Weakly opposed. (Like others, I find multiple values useful.)

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

Neutral.

DrScheme's teaching languages are case-sensitive, and it's not clear to
me whether this increases or decreases confusion for beginners.

Those who prefer case sensitivity in PLT Scheme put "#cs" in front of
an S-expression (usually a module) to make it case sensitive, and this
seems to work well.

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

Strongly in favor.

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

Opposed. (These should all be future work via SRFIs.)

> ================================================================
> EXTENSIONS to R5RS (controversial and probably unnecessary)
> 
> - pattern matching / destructuring

Opposed. (Another SRFI.)

> - abstract data type for continuations
>
> - support composable continuations
>
> - add box types
> 
> - uninterned symbols
>   vs. Chez's globally unique names
> 
> - extended symbol syntax

Neutral.

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

In favor.

> - optional and keyword arguments as in DSSSL

Weakly opposed.

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

Very strongly in favor. (To me, other topics are a waste of time until
this one is settled.)

> - non-hygienic macros
>
> - records

In favor.
 
> - mechanism for new primitive types

I'm not sure what this means.

> - Unicode support

Neutral.

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

In favor.
 
> ================================================================
> EXTENSIONS to R5RS (probably not terribly controversial)
> 
> - multiline comments
> 
> - external representation for circular structures
>
> - #!eof
> 
> - more escape characters
> 
> - require that #f, #t, and characters be followed by a delimiter

Neutral.

> - CASE-LAMBDA

In favor.

> - add COND-EXPAND

Strongly opposed. (We should have a module system.)

> - allow the name of the macro being defined in SYNTAX-RULES to be
>   arbitrary (or _)
> 
> - allow continuations created by begin to accept any number of values
> 
> - tighten up specification of EQ? and EQV? (or otherwise address their
>   portability problems)
> 
> - tighten up specification of inexact arithmetic
> 
> - add +0, -0, +inf, -inf, +nan
> 
> - add bitwise operations on exact integers
> 
> - SRFI 4 homogeneous numeric vectors
> 
> - specify dynamic environment
> 
> - operations on files
> 
> - binary I/O
>   or: new I/O subsystem entirely
> 
> - string code
> 
> - regular expressions
> 
> - command-line parsing
> 
> - hash tables
> 
> - library for dates
> 
> - system operations

Neutral.

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

Strongly in favor.


Matthew



More information about the R6RS mailing list