[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
report on Snowbird authors' meeting
At long last, this is my report on what happened at the Scheme
authors' meeting on 24 July 1988 at Snowbird. The report has
three parts:
1. a summary of changes to the R3RS that will be made in the R4RS
2. a review of the things that still need to be done for R4RS
3. the action taken on each agenda proposal, with a summary of the debate
Hal Abelson chaired the meeting and did a very fine job. About fifty people
attended.
--------------------------------------------------------------------------------
PART 1. Changes that will appear in the R4RS.
These changes are numbered as in the list of proposals as compiled, and edited
capriciously, by J Rees on 13 July 1988. Changes that did not appear in that
list are identified by letters rather than numbers.
1.1. Implementations must provide some way for programmers to work in a
syntactic environment that preempts no lexical conventions of the Report
and reserves no words other than those used in the Report.
1.2. The sets defined by the following predicates will be required to be
disjoint: boolean?, pair?, symbol?, number?, char?, string?, vector?,
procedure?.
1.3. The variables NIL and T will be removed from the Report.
1.5, 1.6, 1.7, 1.8. Certain sentences will be clarified.
1.10, 1.11, 1.12. The syntax of numbers will be changed, becoming closer to
the syntax used in Common Lisp. Changes include:
The radix prefix will precede the sign, eg #x-ab.
The exactness prefix will precede the sign, eg #i-3.
Exponents will be illegal in rational syntax.
Exponents will be illegal unless the radix is 10.
The precision prefix is to be replaced by exponent markers as in Common Lisp,
eg 1S3, 1F3, 1D3, 1L3, 1E3.
Any constant with an imaginary part will be required to have an explicit sign
in front of the imaginary part. The formal syntax, to be written by
Clinger, will be along the lines of [ [ + | - ] a ] (+ | -) [ b ] i.
1.13. A numeric constant will be considered exact unless it contains one of
the following:
#i explicit inexactness prefix
@ polar notation
. an explicit decimal point
# imprecise digits
e exponent marker
s exponent marker
f exponent marker
d exponent marker
l exponent marker
1.14. The list of formal variables in LAMBDA, LET, LETREC, and DO expressions
must not contain duplications.
1.15. RATIONALIZE is to be made exactness-preserving and its ambiguous
specification fixed.
A. The branch cuts for ATAN will be corrected to be whatever Steele says.
B. INTEGER->CHAR will require an exact integer argument.
C. APPROXIMATE will disappear. The one-argument form of RATIONALIZE will
either disappear or be defined so it makes sense without assuming any
particular internal representations. The behavior of various procedures when
given inexact arguments will be clarified: ZERO?, POSITIVE?, NEGATIVE?, EVEN?,
ODD?, NUMERATOR, DENOMINATOR, =, <, >, <=, >=. The semantics of NUMBER->STRING
and STRING->NUMBER will be clarified or changed.
2.1. The following syntaxes and procedures become essential:
CASE, AND, OR, QUASIQUOTE
APPEND with zero or more arguments
REVERSE
MAX, MIN, MODULO, GCD, LCM, FLOOR, CEILING, TRUNCATE, ROUND
+ and * with zero or more arguments
- and / with one argument
some yet-to-be-determined form of NUMBER->STRING, STRING->NUMBER
CHAR-CI?, CHAR-CI<?, CHAR-CI>?, CHAR-CI<=?, CHAR-CI>=? (two arguments only)
CHAR-ALPHABETIC?, CHAR-NUMERIC?, CHAR-WHITESPACE?
CHAR-LOWER-CASE?, CHAR-UPPER-CASE?, CHAR-UPCASE, CHAR-DOWNCASE
MAKE-STRING (with one or two arguments)
STRING-SET!
STRING-CI?, STRING-CI<?, STRING-CI>?, STRING-CI<=?, STRING-CI>=?
(two arguments only)
STRING-APPEND
MAP and FOR-EACH with two or more arguments
OPEN-INPUT-FILE, OPEN-OUTPUT-FILE, CLOSE-INPUT-PORT, CLOSE-OUTPUT-PORT
LAST-PAIR will disappear from the report.
[Note: the following syntaxes and procedures will be the only features
from R3RS that remain inessential in R4RS:
(if E0 E1)
(let* ...)
(do ...)
named let
internal definitions
delay
list-tail
list-ref
- and / with more than two arguments
string-copy, string-fill!
vector-fill!
apply with more than two arguments
force
with-input-from-file, with-output-to-file
char-ready?
transcript-on, transcript-off
The first five will probably appear in the first draft of the IEEE standard
without being qualified as inessential.]
D. A section on immutable structures will be added. Immutable structures
will be defined as pairs, vectors, strings, or other structures for which
it is an error to attempt to assign a new value to an element of the
structure. Data structures that appear as constants will be immutable.
[Note: This is merely a clarification. See the last sentence of section
4.1.2 in R3RS.]
E. Something resembling EXTEND-SYNTAX without WITH and based on
syntactic closures will be added to the Report as an inessential feature,
provided the macro committee delivers something reasonable in time.
F. Nested begin expressions containing DEFINE forms will be flattened and
treated as consecutive DEFINE forms, both at top level and at the head of
lambda bodies. Macros will be permitted to expand into definitions and
BEGIN forms containing definitions.
--------------------------------------------------------------------------------
PART 2. Things that still need to be done for R4RS.
1.10, 1.11, 1.12. Formal syntax of numeric constants: Clinger.
1.15. Clarify semantics of RATIONALIZE, ZERO?, EVEN?, ODD?, POSITIVE?,
NEGATIVE?, NUMERATOR, DENOMINATOR, =, <, >, <=, >=, NUMBER->STRING,
STRING->NUMBER: Dybvig, Bawden, Sussman.
A. Decide on branch cuts for ATAN: Steele.
3.1. Propose macro facility: Bawden, Rees, Dybvig, Heib.
If the macro committee gets stuck, R4RS will go forward without macros.
Although the following proposals were not adopted at Snowbird, there seemed
to be consensus on the general issue but a problem with details. New
proposals were solicited. If a timely and detailed proposal on one of these
issues can survive discussion on RRRS-AUTHORS, then it will go into R4RS.
1.4. Propose major rewrite of section on equivalence predicates:
Miller, Rees, Clinger.
2.2. Propose regularization of procedures: Katz.
4.4. Propose a better name for named let: anyone.
--------------------------------------------------------------------------------
PART 3. Action taken on each agenda proposal.
1.1. Reserved words and portable code. Adopted by acclamation. Noted:
lexical extensions are ok so long as they don't conflict with the lexical
conventions of the Report.
1.2. Disjointness of types. Adopted by acclamation. Two people objected
to requiring (NOT (EQ? #F '())). Promises and ports were considered but were
not added to the list of disjoint types.
1.3. Eliminate NIL, T. Adopted by acclamation.
1.4. EQV? Not adopted. Reasons: The body of the Report should not refer to
the formal semantics. If the body is not precise enough to stand on its own,
it should be made more precise. Locations should therefore be discussed in
the sections on pairs, vectors, strings, and procedures. Sentences should be
collapsed wherever possible. The disjointness of types creates some changes
and should simplify the discussion.
1.5. Change wording of LETREC restriction. Adopted by acclamation after
improving the proposed wording to "One restriction on LETREC is very important:
it must be possible to evaluate each <init> without assigning or referring to
the value of any <variable>. If this restriction is violated, then it is an
error."
1.6. Clarify wording of LETREC. Adopted by acclamation without debate.
1.7. Clarify status of CI. Adopted by acclamation without debate.
1.8. Clarify the specification of TRUNCATE. Adopted by acclamation without
debate.
1.9. Improve the discussion of exactness and inexactness. Not debated per se.
See C.
1.10. Change the syntax of numbers. The syntax of complex numbers occasioned
much debate, with the result summarized in part 1. The discussion of 1.11 and
1.12 was combined with the debate on 1.10, and my notes make it appear that no
separate vote was taken for 1.11 or 1.12. Below I say that 1.11 and 1.12 were
adopted by acclamation because complex numbers were the only source of
controversy.
1.11. Clarify the status of exponents. Adopted by acclamation. It was noted
that the grammar would be clearer if <digit> were <digit 10>.
1.12. Exponents illegal in fractions. Adopted by acclamation.
1.13. Exactness and inexactness of constants. Modified by adding exponent
markers to the list of things that indicate inexactness, and then adopted by
acclamation.
1.14. Make duplicated formals illegal. Adopted by acclamation. Debate
clarified that "illegal" should mean "is an error".
1.15. Clarify semantics of RATIONALIZE. Adopted by acclamation. Note:
the proposal was to change "smallest denominator" to "simplest denominator"
and to make RATIONALIZE exactness-preserving. [Private discussion following
the IEEE meeting raised further issues that need to be addressed.]
A. Branch cuts for ATAN. Adopted by acclamation. The R3RS got the branch
cuts wrong because I copied Steele and Common Lisp, who copied Penrose (?) and
APL. Penrose now says he got them wrong, and Steele says he got them wrong and
wants to change Common Lisp.
B. Require exact argument for INTEGER->CHAR. Adopted by acclamation.
C. Clarify semantics of arithmetic procedures on inexact arguments, and fix
NUMBER->STRING and STRING->NUMBER. Questions about the semantics of these
procedures persist. By acclamation Dybvig, Bawden, and Sussman were given
the task of fixing them. Noted: STRING->NUMBER would be more useful if it
returned false when it failed to parse the string.
2.1. Flush inessential features. For every inessential feature in R3RS, the
chair asked whether anyone objected to flushing it and whether anyone objected
to making it essential. The unanimous decisions were listed in part 1. The
only inessential feature that everyone wanted to flush was LAST-PAIR.
D. Add section on immutable structures. Adopted by acclamation. This
issue arose during debate on making STRING-SET! essential.
2.2. Make procedures more regular. Not debated very much. Katz volunteered
to develop a concrete proposal.
2.3. Underspecification. The value returned by SET! was discussed as an
example. There are at least two distinct useful values that might be
returned, as well as the conservative #!unspecified. No consensus but
probably a useful debate.
3.1. Macros. Pre-adopted by acclamation. That is, we voted to trust a
committee composed of Bawden, Rees, Dybvig, and Hieb. Everyone seems to
want macros, and impatience is beginning to win out over contrary desires
that one's favorite approach to macros be chosen.
3.2. Modules. Not adopted.
3.3. Replace LOAD with INCLUDE. Not adopted.
3.4. First class environments. Not adopted.
3.5. Add EVAL. Not adopted.
3.6. Add second argument to LOAD. Not adopted.
F. Flatten BEGIN forms containing definitions. Adopted by acclamation.
My notes are not clear on how this issue arose, but it may have been part
of the debate on INCLUDE. It was noted that a form of INCLUDE could be
implemented as a macro if we had macros and BEGIN forms were flattened.
3.7. Add LAMBDA*. Not adopted. The main objection seemed to be that
this proposal requires a new kind of stored value (multiple values) that
either is not an expressed value or does not behave like other expressed
values.
3.8. Multiple return values. Not adopted. Debate centered on whether
returning a single "multiple value" should be equivalent to returning
that value normally. A secondary issue concerned whether extra return
values should be ignored or an error. We approached consensus on this.
After much debate it was decided to go on to other issues and let
Dybvig and Hanson discuss the matter in private. Their discussion
later that night led to a conclusion that we don't understand the
issues well enough to charge ahead with either proposal 3.7 or 3.8
or a variation.
3.9. Optional arguments. Not considered, as it was felt that this
would be a more controversial issue than proposal 3.8 on which we had
just spent a great deal of time.
3.10. Record types. Not adopted. Rozas opposes opaqueness, but might
be willing to accept disjointness of new types.
At this point we were nearly out of time, so the chair decided to go
around the room, letting each person state the one change that he or
she would like to make. There was not much time for debate.
3.11. Add TYPE-OF. Not adopted. Noted: a predicate TYPE? would be
more in the spirit of Scheme.
4.20. Change the specification of AND. Not adopted. This proposal
was incorrect in the list of proposals that was sent out. [My fault
-- Clinger] It should have been: "AND will return a true value or
a false value" and does not have to return the value of the last
expression it evaluates.
4.4 Eliminate named let. Most people seemed willing to change the
name of named let. RECUR was suggested but objected to. It was
agreed that we would go away, nominate and agree on a better name,
and use it in R4RS. [So far a number of names have been nominated
but none have been agreed upon.]
4.24. Rename CHAR-READY? to READ-CHAR-READY? Not adopted.
4.5. Eliminate =>. Not adopted.