agenda

[willc@tekchips.crl]

Agenda for the RRRS meeting on Sunday, 24 July.

The agenda is divided into four parts.  The first part consists of relatively
noncontroversial proposals whose adoption in some form is recommended by the
agenda committee.  The agenda committee makes no recommendations concerning
the rest of the agenda.

The second part of the agenda considers general questions of policy.  The
third part consists of major proposals.  Some of these may not be ready for
adoption but would benefit from discussion.  The fourth part consists of all
remaining proposals.


**PART 1: CLEANUPS**

RESERVED WORDS AND PORTABLE CODE.  Require that implementations
provide some way for programmers to work in a syntactic environment
containing no reserved words other than those found in the report,
without requiring that this be the default syntactic environment.

DISJOINTNESS OF TYPES.  Require that the following sets of objects
be disjoint:  booleans, pairs, symbols, numbers, characters, strings,
vectors, procedures.  Issue: add the singleton set containing the
empty list to the list.  Issue: remove characters from the list.
Issue: add promises to the list, or flush force and delay altogether
(see **OTHER PROPOSALS**).

ELIMINATE NIL, T.  Remove nil and t from the report.

EQV?.  Clean up the specification of eqv?, removing the requirement
that it be true of two empty strings or empty vectors.

DUPLICATE FORMALS ARE IN ERROR.  The list of formal variables in
lambda, let, letrec, and do (but not let*) should not contain
duplications.  E.g. (lambda (x y x) ...) is an error.  In the case
of named let, the formals in the initial bindings list should be
distinct, but it is ok (albeit useless) for the "name" to duplicate
a formal.  E.g. (let foo ((x 1) (foo 2)) ...) is legal.

CHANGE WORDING OF LETREC RESTRICTION.  From "...without referring
to the value of any <variable>" to "...without referring to the
value or location of any variable".  Example:

  (letrec ((wanna-be-a-doctor    'doctor)
           (imagine-my-surprise! (begin
                                  (set! wanna-be-a-doctor 'nurse)
                                  'zowie)))
    wanna-be-a-doctor)

CLARIFY WORDING OF LETREC.  Add the word "ALL" as follows:
"...in a letrec expression, ALL the bindings are in effect while
their initial values are being computed..."

CLARIFY MEANING OF QUASIQUOTE.  As in Pavel Curtis's proposal.

CLARIFY STATUS OF CI.  Though CI is described as a suffix,
it is generally just embedded.

CLARIFY THE SPECIFICATION OF TRUNCATE.  Specify the sign of
the result, and specify the absolute value of the result.

IMPROVE THE DISCUSSION OF EXACTNESS AND INEXACTNESS.  As in
R^3.5RS.

CHANGE THE SYNTAX OF NUMBERS.  As in R^3.5RS:  use the exponent
marker to indicate the precision of inexact numbers, and use
3+i4, 3-i4, 3+i, 3-i, +i4, -i4, +i, -i, and 3@3.14159265 for
complex numbers.  Issue: 3+4i would be more in keeping with
common mathmatical practice.

CLARIFY THE STATUS OF EXPONENTS.  As in R^3.5RS:  numbers that
contain decimal points or exponents must be in decimal radix.

EXPONENTS ILLEGAL IN FRACTIONS.  As in R^3.5RS: 3/4e5 is not
legal.

EXACTNESS AND INEXACTNESS OF CONSTANTS.  Constants that contain
no explicit exactness prefix are inexact if they contain any of
the following:

  an explicit inexactness prefix
  an at-sign indicating polar representation
  a decimal point
  a sharp sign indicating a "don't care" digit, as in 123##

A constant may also be inexact if it contains a negative exponent;
this is implementation-dependent.  Otherwise the constant is exact.

  Issue:  3@0     (inexact by above rules)
  Issue:  1e5     (exact by above rules)
  Issue:  1e-5    (implementation-dependent by above rules)


**PART 2: POLICY ISSUES**

FLUSH OPTIONAL FEATURES.  Do away with the distinction between
essential and optional features.  In effect, make everything
essential.  Issue: some optional features should be dropped rather
than made essential; which?

MAKE PROCEDURES MORE REGULAR.  Add vector-copy, list-copy,
list-fill!, list-set!, (make-list k); or remove procedures
to make them more regular across the different kinds of
sequences.  Issue:  what's the policy?  Issue:  generic
copiers, fillers, etc.  Issue: optional or essential?

UNDERSPECIFICATION.  What kinds of underspecification are
desirable?  What kinds are undesirable?


**PART 3: MAJOR PROPOSALS**

MACROS.  No complete proposal is ready for consideration.  The
macro and extend-syntax syntaxes have been proposed as least
common denominator(s) to tide us over until we have a real macro
proposal.

MODULES.  Pavel Curtis, Jonathan Rees, and John Ramsdell have
sketched proposals, but no complete proposals are ready for
consideration.  The next four proposals are related to this.

REPLACE LOAD WITH INCLUDE.  The load procedure is convenient for
interactive program development, but its dependence on an object
with state (the external file system) makes it less satisfactory
than include would be for describing complete programs.
Presumably implementations would retain load as part of their
programming environment even if it were replaced by include in
the report.  Issue:  An alternative is to change the meaning of
load in the report.  Issue:  Include also depends on an external
file system; the only difference is that the dependency is removed
at compile time rather than run time.

FIRST CLASS ENVIRONMENTS.  In my opinion, no proposal for
environments remains on the table.  A proposal could be built
around make-environment, the-environment, build-environment,
Guzowski's with, or Pavel's recently withdrawn proposal.

ADD EVAL.  Add eval to section 6.10.4.  Issue: one or two arguments?
If two, how do you get an appropriate second argument?

ADD SECOND ARGUMENT TO LOAD.  If eval is added and takes a second
argument, then shouldn't a second argument should be added to load
also?

ADD LAMBDA*.  Adopt the Hieb/Dybvig proposal for procedures that
dispatch on the number of arguments they are given, for allowing
multiple values to be stored in variables, and for the & syntax.
This proposal is an alternative to the next two proposals.

MULTIPLE RETURN VALUES.  Add optional procedures values and
with-values such that (values x1 ...) returns values x1 ... and
(with-values thunk proc) calls proc on the values returned by
thunk.  Issue: what do continuations that currently expect one
return value do when given zero values or more than one value?
The most popular answers are:

  a.  It is an error.
  b.  Ignore extra values; it is an error if there are no return
      values.
  c.  Ignore extra values; the continuation gets an unspecified
      value if there are no return values.
  d.  Ignore extra values; the continuation gets #f if there are
      no return values.

OPTIONAL ARGUMENTS.  Add an optional #!optional syntax to lambda
expressions to support optional arguments:

  (lambda (x #!optional y z . w) ...)

If not supplied, y and z are bound to new locations holding a
special default object.  Add the procedure default-object? so that
(default-object? y) is true if y is not supplied.  It would be
possible to pass the default object as an actual argument, thereby
making it possible to obtain the default for y while specifying z
explicitly.

RECORD OBJECTS.  Jonathan's proposal:

  make-record-type
  record-constructor
  record-predicate
  record-accessor
  record-updater

  Issue:  If the object returned by make-record-type isn't a type
  but a "descriptor", then maybe the name is wrong.

  Issue:  what about record-copier?

  Issue:  inheritance.

  Issue:  something resembling type-of.

  Issue:  Initialization of all fields, positionally, rather than
  initialization of selected fields by name.

  Issue:  Optional?


**PART 4: OTHER PROPOSALS**

CHANGE WORDING OF SET! RESTRICTION.  From "<Variable> must be
bound in some region enclosing the set! expression or at top
level" to "<Variable> must be bound in an enclosing lexical
environment".  Issue: need examples of code that illustrate
the intended differences between the two wordings.

FORMAL SEMANTICS FOR NUMERIC CONSTANTS.  As proposed by Clinger,
who doesn't think it is necessary.

ELIMINATE DO.  Remove do from the language.

ELIMINATE NAMED LET.  Remove named let from the language.

ELIMINATE =>.  Remove the => notation from the language.

ELIMINATE CASE.  Remove case from the language.

ELIMINATE FORCE AND DELAY.  Or make promises disjoint from other
types.

ELIMINATE LAST-PAIR.  Remove last-pair from the language.

ELIMINATE NUMERIC FORMATS.  Eliminate (or redesign or simplify)
the format arguments to number->string.

ELIMINATE CALL-WITH-CURRENT-CONTINUATION.  Remove
call-with-current-continuation because it makes programs hard to
understand.

DEFINE WITH NO EXPRESSION.  Optionally allow (define x) for top level
definitions only.  Issue: why not for internal definitions?  Issue:
If it becomes available for internal definitions, then it should also
be available for letrec, let, let*, named let (?), and do (??).

ADD CALL.  Add essential syntax: (call proc arg1 ...).

ADD STATIC.  Add essential syntax: (static id).

PEEK-CHAR.  Add a peek-char procedure.  Issue: essential?

ADD EQ-HASH, EQV-HASH.  (eq? x y) implies (= (eq-hash x) (eq-hash y)),
and (eqv? x y) implies (= (eqv-hash x) (eqv-hash y)).  Implementations
are encouraged to make the converse as probable as possible.

ADD DAYS-AFTER-J2000.0.

VALUE RETURNED BY ONE-ARMED IF, COND.  Specify that (if E0 E1) returns
#f if E0 is false, and that (cond ...) returns #f if no clauses apply.

VALUES RETURNED BY SIDE EFFECTS.  Change the semantics of
(set! x e), (set-car! x e), (write e p), et cetera, so that
they return the value of e.  Issue: why not return #!unspecified?

LEFT TO RIGHT EVALUATION OF ARGUMENTS.  Change the semantics of
procedure calls so that expressions are evaluated from left to
right.

LEFT TO RIGHT EVALUATION OF DEFINITIONS.  Change the semantics
of internal definitions so that they are evaluated from left to
right.  Issue: do the same for letrec?

CHANGE THE SPECIFICATION OF AND.  Change and so it always returns
#t or #f.  Issue:  the last position of an and becomes non-tail-
recursive.  Issue:  If this proposal is not adopted, must and
return the first false value it sees, or can it simply return #f?

RENAME CHARACTER COMPARISON PREDICATES.  Change char=? etc to
char= etc.

RENAME SET! TO SET.

RENAME SET-CAR! TO SET-CAR, SET-CDR! TO SET-CDR.  Issue:
non-destructive versions make sense even though they're not in the
report.

RENAME CHAR-READY? TO READ-CHAR-READY?.  Issue: name:
READY-TO-READ-CHAR?  Issue: replace instead
with read-char? (TYI-NO-HANG)?

RELAX THE LETREC RESTRICTION.  Require implementations to find
an order that works, if any does.  Issue:  not computable?

DON'T SPECIFY WHETHER THE EMPTY LIST COUNTS AS TRUE OR FALSE.