[R6RS] draft minutes of 18 September 2004 meeting

[William D Clinger]

18 September 2004
Snowbird, Utah
9am

Attending:
Marc Feeley, Kent Dybvig, Will Clinger, Matthew Flatt,
Manuel Serrano, Mike Sperber
Absent:
Richard Kelsey

****************************************************************

How should we vote on issues?  Majority vote, taken electronically.
Should revote on everything before final editing of R6RS, to make
sure it hangs together, and to ratify preliminary decisions.

****************************************************************

Modules.

What are modules?

Matthew: separate compilation, managing universal namespace,
    refer impl [sic]

Will: putting pieces together without name clashes, hierarchical

Mike: interchangeable parts

Marc: encapsulation, managing namespace

Manuel: to organize programs in files, initialize things, name
    entry points, etc

Kent: all of the above except maybe files; namespace management,
    analyzability, compile-time link

Extensive discussion of modules followed.

****************************************************************

Will's notes on portability.

Discussion:
  difficulty of implementing the standard
  reference implementations necessary but not sufficient

Reference implementations needed for:
  floating-point i/o
  macros
    SYNTAX-RULES
    SYNTAX-CASE
  modules
  records
  various libraries

****************************************************************

Discussion of records.

****************************************************************

New issues raised by Mike Sperber:

Brackets as alternatives to parentheses.
  Must be matched.

When is quote required?
  E.g. empty list.

Remove SET-CAR!, SET-CDR!

****************************************************************

Traversal of current list of issues.

  DELETIONS from R5RS

    - remove transcript-{on,off}

Yes, remove TRANSCRIPT-{ON,OFF}.

    - remove FORCE and DELAY

Remove them from the core language, but put them in a standard
library.

    - remove multiple values

Leave them in R6RS.

  INCOMPATIBLE CHANGES to R5RS

    - make syntax case-sensitive

Punted after considerable discussion.

  EXTENSIONS that would break implementation-specific extensions

    - specify evaluation order

Leave the order of evaluation undefined for calls, LET, etc.

Add LETREC* and give internal definitions the semantics of LETREC*
instead of LETREC.

    - support for processes

Not in R6RS.

    - support for network programming

Not in R6RS.

    - object-oriented programming

Not in R6RS.

    - external representation for records

Desirable.  Depends on what we do for records.

    - serialization

Write/read serialization of <DATUM> should be required.

  EXTENSIONS to R5RS (controversial and probably unnecessary)

    - pattern matching / destructuring

Manuel will show us what he has in mind.

    - abstract data type for continuations

Punted after much discussion.  Marc was proposing something like

    (continuation-capture f)
    (continuation-return k ---)
    (continuation-graft k f)

Kent proposed primitives like

    newprompt
    pushprompt
    letsubcont
    pushsubcont

Mike pointed out that invariants such as the DYNAMIC-WIND
invariants are preserved by Marc's primitives but not by Kent's,
so we have to be careful about giving Kent's primitives to Scheme
programmers.

Kent requested the following invariant, which is not required by
the R5RS but would make it easier to write portable tracers and
other tools.

  (call/cc (lambda (k1) (call/cc (lambda (k2) (eqv? k1 k2)))))

    - support composable continuations

Punt.

    - add box types

No.

    - uninterned symbols

Generally positive reaction.  What is meant is something like

    (gensym)
    (gensym "name")

which returns something that prints like

    #{ name uname }
or  #:name^B---

where the uname is hoped to be unique (uuidgen), and isn't generated
until someone uses SYMBOL->STRING on the symbol.

    - extended symbol syntax

Goal is write/read invariance.  Clinger doesn't mind extended symbol
syntax in data, but doesn't want to expand the space of identifiers
that can appear in programs.  But what about generated programs?
They could follow the rules too.

But why do people want symbols with such weird print names?  Mainly
because they're using symbols when they ought to be using strings.
Why not restrict the argument to STRING->SYMBOL instead?  General
agreement on this.

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

Yes.

    - optional and keyword arguments as in DSSSL

Punt.  Why not add CASE-LAMBDA and define standard macros for
optional and keyword arguments that expand into CASE-LAMBDA?
The argument centered upon efficiency, and seemed to be based
upon the incorrect belief that putting keyword arguments into
the core language would make them significantly more efficient.

  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"

Punt, but see below.

****************************************************************

Errors and exceptions.
Presentation by Mike Sperber

Consensus:  Doesn't try to do everything, but probably does
most everything we need for R6RS.  Still need to specify the
semantics of a couple of things, being careful not to preclude
features we might want to add in R7RS.

****************************************************************

Subcommittees.

In the list below, urgent items (that we want to work on before
meeting again on Monday night here at Snowbird) are marked with
asterisks.

  * macros                     Kent, Matthew
  * records                    Will (Kent, Marc will review)
  * arithmetic                 Will, Mike, Kent
  * modules                    Kent, Mike, Manuel
  * pattern matching           Manuel
    Unicode                    Matthew, Mike, Marc
    i/o                                        [look at SML]
    exceptions                 Will
    continuations

****************************************************************