[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