[R6RS] Position on list of issues

[Marc Feeley]

For the record, here is my position on the list of issues (I was going to
wait until the merging of all the positions, but it is probably best to
do it like everyone else).

Marc

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

Yes.

> - remove FORCE and DELAY

No, they are useful.  They could be put in a standard library however.

> - remove multiple values

I think multiple values are a wart in the language.  I'm only mildly in
favor for removing them and will not pursue the issue unless others
support removal.

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

I support this for two reasons, 1) more elegant interfacing with
languages that are case-sensitive, 2) because case-insensitivity is a
concept that is dependent on natural language (English, French,
Turkish, etc).  The first reason is arguable and very much a question
of taste but the second reason is hard to go against, especially if
source code can be written in Unicode.  The classic example is that
the lowercase version of "I" is "i" in most languages but "dotless-i"
in Turkish.  So "i" and "I" are not the same case-insensitive
identifiers to a Turk.  Adopting a case-sensitive syntax would
eliminate this issue.

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

Neutral.  I don't think it solves any problems and it would be harder
for the compiler to perform some optimizations.

> - support for processes

Neutral.  Processes/threads are important but I doubt we can arrive at
a consensus on a process model and API.  I think we should discuss
this further.  Perhaps my threading SRFIs can be used as a starting point.

> - support for network programming

Neutral.  Like processes I doubt we can arrive at a consensus on a
networking model and API.  It would be best to start with a SRFI.

> - object-oriented programming

Against.  It would be best to start with a SRFI.

> - external representation for records

I support this so that debugging and textbooks can be more consistent
over implementations.  While we are at it we should also standardize
on an external representation for procedures and ports.

> - serialization

Serialization of records is useful for distributed systems (i.e.
exchanging records between different processes) and for storing
records in files.  It would be good to allow such communication of
records between different implementations of Scheme, so a standard
serialization format is needed.

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

I'd like to discuss this because pattern matching becomes very useful
in the presence of records.

> - abstract data type for continuations

I strongly support this and it should be in the core.  Call/cc
would go into a standard library.

> - support composable continuations

I'm not sure what this means.

> - add box types

I weakly support this.

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

I support uninterned symbols (I don't know Chez's globally unique names
well enough).

> - extended symbol syntax

I strongly support this.

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

I support this.

> - optional and keyword arguments as in DSSSL

I support this.  I do not feel case-lambda is an appropriate
substitute because in my view it leads to unelegant code in the common
case.  Normally the same core computation is performed by each
combination of optional arguments and with case-lambda this requires
defining a separate procedure performing this core computation.
Moreover keyword arguments implemented as a macro will be very
inefficient (construction and traversal of the list of parameters).  I
think keyword arguments will be necessary for some I/O procedures that
would otherwise have too many parameters with no obvious ordering (for
example an "open-file" procedure that needs the filename, the creation
mode, the character encoding, the end-of-line encoding, etc).

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

I strongly support this.

> - non-hygienic macros

I strongly support this.

> - records

I strongly support this.

> - mechanism for new primitive types

I strongly support this, but to me this just means records are new types.

> - Unicode support

I strongly support this.

> - errors and exceptions

I strongly support this.

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

I support this for most errors (some errors are too hard to detect).
I think the standard should explicitly say which exception is raised
by each type of error.

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

Yes.

> - external representation for circular structures

Yes.

> - #!eof

Yes.

> - more escape characters

Yes.

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

Yes.  It will make the following external representations possible:
#f64(...) and #record-name(...) whether they are standard or
implementation specific extensions.

> - CASE-LAMBDA

I'm opposed.  Both optional and keyword arguments are needed.

> - add COND-EXPAND

Yes.  This will make the SRFI process more useful and allow
introspection.

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

Neutral.

> - tighten up specification of inexact arithmetic

Yes.

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

Yes.

> - add bitwise operations on exact integers

Yes.

> - SRFI 4 homogeneous numeric vectors

I think homogeneous numeric vectors are important, but I'm not sure
SRFI 4 is the best way because of the explosion of primitives (on
the other hand this seems necessary for performance).  I believe
byte vectors will be necessary for binary I/O.

> - specify dynamic environment

Yes.

> - operations on files

Yes.  But we need to be careful and stay portable to various file
systems.

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

Yes.  Scheme I/O currently sucks.

> - string code

I'm not sure what this means.

> - regular expressions

Neutral.  To me regular expressions are an example of a user library
(i.e.  not a "standard" library specified in the R6RS).

> - command-line parsing

Neutral.  Like regular expressions, this should also be a user library.
However it might be useful to standardize on scripting (i.e. features
that are necessary to write scripts and the syntax of scripts).  The
problem is that this is very operating-system specific.  I wonder if
we shouldn't add operating-system specific libraries to the R6RS, in
particular a UNIX section and a Microsoft Windows section.  These
sections would specify features that apply to these systems only.

> - hash tables

Neutral.

> - library for dates

Neutral.

> - system operations

Neutral (I would be more in favor if we have operating-system specific
sections).

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

Strongly in favor (but I realize this will require a lot of discussion).

> ================================================================