[R6RS] First progress report

[Marc Feeley]

I have finished writing the first progress report for the steering
committee.  Please have a look and tell me if I should add anything or
if I have misrepresented the committee.  I have merged Michael's draft
and added some more details (is it too much?).

Please respond soon.  I want to send the report this thursday.

Marc


      First progress report of the R6RS editors committee

                        Marc Feeley

                      August 31, 2004

At the 2003 Scheme workshop in November the strategy committee
(Bawden, Clinger, Dybvig, Flatt, Kelsey, Serrano, Sperber) was
mandated to nominate a steering committee and editors committee to
work on the R6RS standard.  In January 2004, the editors committee was
nominated (Feeley (editor in chief), Clinger, Dybvig, Flatt, Kelsey,
Serrano, Sperber).

On January 19 a private mailing list was created to keep a record of
the email exchanges between the editors (r6rs at iro.umontreal.ca).
Although some editors suggested that a more open process would be
desirable we chose to keep this mailing list private to avoid outside
interference and keep the process disciplined and focused.  Sometime
in the future the archive of the discussions will be made public so
that the reasons for the design decisions are clear.

Because of the expected difficulty in managing productive discussions
for a 7 member committee over email, we adopted some ground rules for
ensuring progress.  If an editor does not participate in an email
discussion within a reasonable "time limit" (which was set to 7 days),
then the other editors can assume that that editor does not have an
opinion on the subject (or does not want to voice his opinion) and can
be ignored (in the discussion, in a vote, etc).  I think this has been
helpful.

The subject of backward compatibility was also discussed early on.
That is, will R5RS code work unchanged in a R6RS compliant Scheme
implementation?  Our position is that backward compatibility is
desirable but that there may be some incompatibilities (for example at
the lexical syntax level) that prevent R5RS code to work under R6RS.
Our first objective is to improve the Scheme language.  Backward
compatibility, while important, is a secondary objective.

We then set off on our first technical task: come up with a list of
goals that is more precise than the one in the draft charter (which
has the 4 items: produce a core Scheme specification, define a module
system, define a macro system, designate library modules).  Our plan
is to use this list of goals to organize the design process, to
identify which changes are uncontroversial (and thus easier to
standardize) and those that will require considerable efforts (and
where consensus may not be achievable during the R6RS design process).

All the editors were polled to get a list of specific issues that they
think need to be addressed in the R6RS design process (features the
committee should consider adding/removing).  At the end of March we
had merged all the editors' lists into a single list with each
editor's position.  At this point there had been very little technical
discussion of these issues (on purpose), so that we could order the
issues and discuss them in a disciplined way.  As suggested by Will
Clinger, the list was organized in the following categories:

  - deletions of R5RS Scheme features
  - incompatible changes to R5RS Scheme
  - extensions that could be entirely compatible with R5RS Scheme
      - but would break some implementation-specific extensions
      - but would be controversial and aren't worth it
      - that are controversial or difficult but necessary
      - that are probably uncontroversial

Below is the list of issues, without each editor's position.  Note
that this list is still open to be expanded as new issues arise in the
design process.

-----------------------------------------------------------------------------

  DELETIONS from R5RS
  
    - remove transcript-{on,off}
    - remove FORCE and DELAY
    - remove multiple values
  
  INCOMPATIBLE CHANGES to R5RS
  
    - make syntax case-sensitive
  
  EXTENSIONS that would break implementation-specific extensions
  
    - specify evaluation order
    - support for processes
    - support for network programming
    - object-oriented programming
    - external representation for records
    - serialization
  
  EXTENSIONS to R5RS (controversial and probably unnecessary)
  
    - pattern matching / destructuring
    - abstract data type for continuations
    - support composable continuations
    - add box types
    - uninterned symbols
    - extended symbol syntax
    - add LETREC*, define internal DEFINE in terms of it
    - optional and keyword arguments as in DSSSL
  
  EXTENSIONS to R5RS (controversial or difficult but necessary)
  
    - module system
    - non-hygienic macros
    - records
    - mechanism for new primitive types
    - Unicode support
    - errors and exceptions
    - require mode where "it is an error" means "an error is signaled"
  
  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
    - CASE-LAMBDA
    - add COND-EXPAND
    - 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
  
  EDITORIAL CHANGES
  
    - split language into core and libraries
  
  ADDITIONAL EXTENSIONS
  
    - support for expression comments
    - support for a subset of Common Lisp format (in a library)

-----------------------------------------------------------------------------

Because of the central role of the module system and its probable use
in splitting the Scheme language into a core and libraries, we decided
that the most pressing issue was the design of the module system.  Our
starting point was the "strawman module system" proposed by Matthew
Flatt, which is based on the MzScheme system.  Various aspects of the
proposed system were discussed, mainly to understand it better and to
add constructive criticism.  Because many aspects are interrelated, we
did not achieve consensus on any specific aspect (nor did we really
try to achieve it given that this is early in the design process).
Here are some of the aspects that were discussed:

  - name to give a "module" (package, unit, library, capsule, program, ...)
  - how are modules "linked" (for statically linked executables, for
    dynamically linked programs, for scripts, for "REPL" type programs)
  - mapping of modules to files, one or multiple modules per file
  - should internal modules be allowed

Over May and June the discussion on the module system was slow and
only two of the seven editors were active.  At the end of June I
suggested that the reason for this apathy may be a lack of practical
experience with the proposed module system (the two editors that were
active both had experience with the MzScheme module system).  I
proposed that we should work on building a portable implementation of
the module system so that the editors can all experiment with it in
our own Scheme implementation.  This would get the editors more
involved in the details of the module system, allow proposed changes
to be made and evaluated on-the-fly by changing the portable
implementation, and the resulting public-domain code would greatly
increase acceptance of R6RS by other implementors.  It still remains
to be seen if this portable implementation becomes a reality as it
represents quite a bit of work.

Kent Dybvig noted that there are few differences between the module
system proposed by Matthew and the one in Chez Scheme.  This prompted
an effort by Matthew and Kent to design a new module system that
combines both systems.  There has been a very active discussion since
then (in fact I still have some catching up to do on the discussion).

We have decided to have a whole day meeting (September 18) in Snowbird
to discuss these issues face to face.  All editors will be there,
except for Richard Kelsey.  We expect the module system to be the main
topic of discussion and to make significant progress and to start
discussing other issues on our list.