Minutes of the Scheme meeting etc.

[willc%tekchips.tek.com@RELAY.CS.NET]

Minutes of the Scheme meeting at MIT on Saturday, 27 June 1987

Attendees included:

Hal Abelson (MIT)
Norman Adams (Tektronix)
David Bartley (Texas Instruments)
Alan Bawden (MIT)
Gary Brooks (Indiana U)
Terry Caudill (Texas Instruments)
Stewart Clamen (BBN/CMU)
Will Clinger (Tektronix)
Olivier Danvy (Copenhagen U)
Bruce Duba (Indiana U)
Kent Dybvig (Indiana U)
Matthias Felleisen (Indiana U)
Anne Hartheimer (Semantic Microsystems)
Chris Haynes (Indiana U)
Bob Hieb (Indiana U)
Morry Katz (Rockwell/MITRE)
Richard Kelsey (Yale)
David Kranz (Yale)
Eugene Kohlbecker (U Rhode Island)
Jim Miller (MIT/Brandeis)
Jim Philbin (Yale)
Kent Pitman (Symbolics)
Eric Ost (Indiana U)
John Ramsdell (MITRE)
Jonathan Rees (MIT/DEC)
Bill Rozas (MIT)
Gerry Sussman (MIT)
Mitch Wand (Northeastern U)
Peter Williams (U Illinois)

After much rearrangement of chairs and table, Mitch Wand opened the meeting
around nine-thirty.  The participants introduced themselves and, if they
wished, explained what they use Scheme for and what they want for and from
Scheme.

ENVIRONMENTS

Then Hal Abelson instigated "a sample foray into content" by asking
whether anyone was so absurd as to think that pattern matching is good
or first class environments are bad.  Gerry Sussman said that first class
environments as in MIT Scheme are a disaster but that another kind
was useful.  Bill Rozas elaborated by saying that (THE-ENVIRONMENT)
is too powerful; experience at MIT showed that it was primarily used
in situations where

    (build-environment <base-environment>
      (define ...)
      (define ...)
      ...)

would suffice.  The environment resulting from BUILD-ENVIRONMENT could
then be used as an argument to EVAL.  The effect of top-level definitions,
as in (EVAL '(DEFINE ...) ENV), is still a thorny question.  MIT's view
is that its incremental definition semantics is just a debugging tool.
Gerry suggested that if you don't specify a base environment to
BUILD-ENVIRONMENT then you should get an empty one.

Jonathan Rees pointed out that ML-style modules need to be studied as an
alternative.  Norman Adams observed that he saw environments being used
in two different ways:  (1) programming in the large (modules); (2) tables
indexed by symbols; he stated that the first was a good use but the second
was bad.  Jonathan contrasted environments with modules, saying that the
module problem was to hook files together without having to use a gigantic
LETREC, while environments and EVAL were useful mainly for performing a
kind of reflection in the sense of Brian Smith's thesis.

Gerry explained his derivation of a sine routine without using magic
constants as an example of a legitimate use of EVAL.  Against complaints
from Will Clinger that people needed to be discouraged from using EVAL,
he said "Our job is not to protect losers from themselves, but to
provide winners with what they need to win."

Kent Pitman then presented T's original approach of breaking EVAL into
smaller pieces that might reflect the stages of compilation and linking
that are involved in separate compilation.

A committee was formed to think about EVAL and environments and to
report back.  It was suggested that the members should be Kent Pitman,
Kent Dybvig, Alan Bawden, Jonathan Rees, and one of Bill Rozas and
Chris Hanson.

YELLOW PAGES (LIBRARY)

Bill Rozas was appointed as the first librarian, or keeper of unsupported,
user-contributed software.  Anne Hartheimer will provide some assistance
at first.  Contributions to the library should be sent to
scheme-librarian@mc.lcs.mit.edu.

MULTIPLE RETURN VALUES

Multiple return values were tabled after much discussion, little
agreement.

SHOULD COLON REALLY BE AN EXTENDED ALPHABETIC CHARACTER

Yes.

PATTERN MATCHING

No change, to be left to the library.

NUMBER SYNTAX

Students find it confusing that 0+3i works but 3i doesn't.  Alternative
syntaxes were discussed briefly.

Questions were raised about the semantics of exactness and inexactness.
Concerning input syntax:  Is 12.5 exact?  What to make of #e#s12345?
It was suggested that (> #i5 #i4) should cause smoke to come out of the
machine.

This discussion was continued on the afternoon of the second day.

The meeting adjourned about five o'clock.


================================================================
Minutes of the Scheme meeting at MIT on Sunday, 28 June 1987

[Attendance was not noted the second day, but Julian Padget (U Bath) was
one addition to the first day's roster.]

Mitch Wand called the meeting to order around nine o'clock.

Alan Bawden explained the macro proposal that he had posted to RRRS-AUTHORS.
It seemed to be pretty much the right thing, but a number of questions
remain:

    What is its relationship to expansion-passing style?

    Where do you get the expand-time environment?  Can you change it?

    Can macros return DEFINE forms?

    How do "top level" macro definitions work?

    Should free variables in a file be resolved as absolute or as
    relative to a LOAD-environment?

    Should atomic, e.g. PI, macro forms be supported?

    Does anyone have a nice user interface for the macro machinery?

    Can a symbol be an identifier (variable) and a macro keyword at
    the same time?

    Which of EVAL, COMPILE, EXPRESSION->VALUE, etc, takes a syntax
    table argument?

Matthias Felleison complained that the proposal was too powerful and/or
concrete.  Mitch Wand characterized Matthias's concerns as:

    What is the nature of the input language?  It was agreed that it
    consist of lists and preprocessed expressions.

    What is the nature of the output language?  It was agreed that it
    would be abstract, and didn't matter.

    Should there be restrictions on the possible transformations?
    This seemed to be the essence of Matthias's objections.

Matthias agreed to post a more formal statement of his concerns to
RRRS-AUTHORS.

A straw poll indicated that nearly all were in favor of moving forward
from Alan's report.

CUSTOMIZABLE READER

Will Clinger solicited comments about a customizable reader he was
proposing for the yellow pages.  The proposed reader did not solve
the main problem that people seemed to want customizable readers
for, namely the need to load code that was written with different
lexical conventions.

NUMBER PROPOSAL

Gerry Sussman and Will Clinger then presented a revised number syntax
and semantics they and David Bartley had worked on the previous evening.
Probing questions revealed that the semantics of inexact numbers were
still unclear, and the matter was tabled after much argument.

EuLISP

Julian Padget presented a summary of generic procedures in EuLisp.

EQV?

Bill Rozas requested that the R3RS be changed to permit (EQV? "" "")
to be false, because empty strings are extensible in MIT Scheme.  This
was opposed by Will Clinger, on the grounds that extensions were
permissible only insofar as they were not in conflict with the language
specification.  Much irrelevant discussion ensued concerning English
descriptions versus formal semantics, the social value of lawyers, and
the lessons of history concerning the decline and fall of programming
languages.  When discussion returned to the technical issue, the
participants were in no mood to agree.

OPTIONAL PROCEDURES

It was suggested that optional procedures should either be made essential
or moved to the yellow pages.  The general feeling, however, was that
the non-essential procedures helped to define a layered language, which
was good.  Bill Rozas suggested that the "yellow pages" library could
contain a supported section containing implementations of the standard
but non-essential procedures.

A committee was appointed to think about language stratification:  David
Bartley, Bruce Duba, Jim Miller, Bill Rozas, and Gerry Sussman.

NEXT MEETING

People from Indiana University offered to host the next meeting, in the
fall.  [My notes do not show the year; I assume the next meeting would
be in the fall of 1988.  Question:  Why not have it at the ACM Conference
on Lisp and Functional Programming?]

The meeting adjourned about five o'clock.

================================================================
Feeling that the weekend meeting had not accomplished all that needed
to be accomplished, a small group of implementors met on Tuesday evening
around six o'clock.  Present were David Bartley (TI), Will Clinger
(Tektronix), Chris Hanson (MIT), Jonathan Rees (MIT), and Bill Rozas (MIT).
It was noted that Chez Scheme was not represented at all, and that T was
represented only by Jonathan.  Agreements made by this small group are
certainly not official or binding on anyone (as indeed is true of decisions
made by the larger group), but they may be of interest as an indication of
the direction certain implementations are going.

[My notes record the topics in the order in which they were proposed for
the agenda, not the order in which they were discussed.]

MACROS

The situation is pretty much ok.  It looks like most of the work is going
to have to be done by people at MIT, because that's where the largest
concentration of macrologists seems to lie.

ENVIRONMENTS & MODULES

Let's get some serious discussion going on RRRS-AUTHORS.  This is important.

STRUCTURES & OPAQUE OPBJECTS

We didn't even touch on this over the weekend, though Norman Adams had
prepared a list of issues.  Norman should post to RRRS-AUTHORS in order
to get something going.  This is also important.

OPTIONAL ARGUMENTS

We agreed to use the #!OPTIONAL syntax as in MIT Scheme.  For example,

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

evaluates to a procedure with one required argument, two optional arguments,
and a rest argument.  How do you tell if an optional argument is supplied?
It is not supplied if its value satisfies the DEFAULT-OBJECT? predicate.
For example, the WRITE procedure might be written

    (define (write x #!optional p)
      (let ((p (if (default-object? p) (current-output-port) p)))
        ...))

A feature of this approach is that the caller can pass a default object
as an argument, thereby faking an unsupplied argument.  This is nice
when you want to supply a value for one optional argument without
supplying for any other optional arguments that precede it in the
argument list.

We did not decide on a syntax for default objects.  This may have been
an oversight.  You can get a default object by writing

    ((lambda (#!optional x) x)).

MULTIPLE RETURN VALUES

We agreed on the names VALUES and WITH-VALUES for the procedures that
return and accept multiple values, respectively.  VALUES takes any
number of arguments and returns them as multiple values.  WITH-VALUES
takes two arguments, of which the first is a thunk that may return
multiple values and the second is a procedure to be called on the
values returned by the thunk.

Since the five or six alternative semantics that people are considering
are linearly ordered by upward compatibility, it doesn't matter too
much what particular implementations do in the short term.  Texas
Instruments will probably implement a semantics in which a continuation
that expects a single return value will accept any number of return
values, ignoring extra return values and seeing #F as the return value
if there are actually no return values.

EQUIVALENCE PREDICATES

The section on equivalence predicates in R3RS was a noble try, but it
satisfied neither those who wanted an abstract, portable definition of
EQV? nor those who wanted EQ? to be an thoroughly implementation-dependent
notion of object identity.  Will Clinger volunteered to rewrite the
section, basing it on a notion of object identity implemented by EQ?
that is specified partially in an implementation-independent way, allowing
unspecified behavior to vary at the whim of implementations.  EQV? would
then be a less implementation-dependent abstraction of EQ?.  The description
of EQUAL? also needs to be tightened up.

The behavior of EQV? on empty strings and empty vectors would be left
implementation-dependent.  The behavior of EQ? and EQV? on procedures
would be left as in R3RS; that is, EQ? and EQV? would have to return
true of procedures created by the same evaluation of a lambda expression,
would have to return false of procedures that behave differently (for
example because their local state is different), and would be
implementation-dependent on procedures that behave identically even
though they might have been created by different evaluations of a lambda
expression or lambda expressions.

One effect of these changes will be to make EQV? more like Common Lisp's
EQL procedure.

TOP LEVEL DEFINE SYNTAX

We considered whether the change in the 1986 Scheme standard that made
(define (foo ...) ...) equivalent to (define foo (lambda (...) ...))
instead of (define foo (rec foo (lambda (...) ...))) might have been
a mistake because of the efficiency issue.  We decided that we liked
the way it was done in the 1986 standard, but that it was ok for
implementations to default to a "benchmark mode" that treats such
definitions as in the 1985 standard, provided there is a way to
disable benchmark mode.

CONDITION HANDLING

We cannot consider a standard condition (exception) handler until we
have a standard list of exceptions, interrupts, i/o errors, and syntax
errors.  We also need some way to associate handlers with conditions
dynamically; fluid variables would be one possibility but are more
general than necessary for this use.

INTEGRABLE DECLARATIONS, CONSTANT DECLARATIONS, AND BLOCK COMPILATION

Most of the perceived need for these would go away if we had a good
enough module facility.  Implementations can in the meantime experiment
with block compilation, knowing that most of the work should be
salvageable when modules arrive.

Insight:  To declare that something is integrable not only declares it
a constant, but also advises the compiler that constant folding is
worth attempting.

INPUT EDITOR

Jonathan Rees proposed a procedure to make it possible to write a
portable reader that supports editing of input in the native style
on machines whose native style is to evaluate expressions immediately
when the closing parenthesis is typed.  He was encouraged to submit
implementations to the yellow pages library.  This seems to be a case
where non-portable implementations of a portable concept is appropriate
for the library.

PEEK-CHAR

Jonathan pointed out that the standard input procedures documented
in R3RS are not powerful enough to write a portable reader, because
Scheme lacks PEEK-CHAR and equivalents.  We know that all major
implementations except possibly Chez Scheme have a PEEK-CHAR
procedure.  We'd like to add PEEK-CHAR to the R3RS if there are no
major objections.

FLUID VARIABLES

We felt that MIT has the best semantics for fluid variables.  Its
greatest weakness is its possible inefficiency on multi-tasking
and multiprocessor implementations, but the implementors of MIT
Scheme have some ideas that may solve that problem.

The meeting adjourned around midnight.

================================================================
End of minutes.