DEFINE -- a concrete proposal

[willc%tekchips.tek.csnet@CSNET-RELAY.ARPA]

I propose that section 4.1.0 of the 22 May 1986 draft be clarified to
read as follows:

    At the top level of a program, a definition

        (define <variable> <expression>)

    has essentially the same effect as the assignment expression

        (set! <variable> <expression>)

    if <variable> is bound.  If <variable> is not bound, however,
    then the definition will bind <variable> before performing
    the assignment, whereas it would be an error to perform a
    set! on an unbound variable.

        [examples go here]

    Top level definitions are essential; all Scheme implementations
    must support them.

    Some implementations of Scheme use an initial environment in
    which all possible variables are bound to locations, most of
    which contain undefined values.  Top level definitions in
    such an implementation are truly equivalent to assignments.

In my opinion, this is merely a clarification because the draft
does not say that the initial environment must contain only the
variables mentioned in the report, and it is in fact the case
that most implementations supply variables that don't appear
in the report.  Furthermore, even if unbound variables exist,
the phrase "it would be an error" indicates that implementations
are not required to complain when one is assigned, so an
implementation is free to do something random (like bind the
variable and do an assignment) instead of signalling the error.

The phrase "Some implementations of Scheme" is the very same
neutral phrase used at the beginning of Section 4.2 on internal
definitions.  Thus the report would be neutral between those
who for whatever reason want to assign variables before they
declare them and those who for whatever reason prefer the
internal definition syntax to LETREC.

Since this is only a clarification of what is already implicit
in the report, I believe this proposal should satisfy those who
prefer the status quo.  I believe it should also satisfy those
who with Mitch are arguing for the following:

    An implementation may have a top level (initial, whatever)
    environment in which every possible identifier is bound
    (though only some are initialized).

    This would allow programs in that implementation to do a set!
    on a global variable (excuse me, a variable in the current
    top-level environment) from an internal scope without having
    to explicitly bind the variable in the initial scope.  It would
    also allow MIT-style define to proceed, as it does not require
    the existence of a distinguished global environment.

Mitch is entirely right that his proposal retains the spirit of
the Brandeis agreement on this issue.  Though Jonathan said in
his reply to Mitch that he wouldn't have too much problem with
adding this clarification to the report, he insisted that it should
be "accompanied by some mention of the fact that some implementations
have principled reasons for not having this feature".  I say that
stipulation is unfair -- the report doesn't contain any of the
principled arguments against internal definitions or against the
fancy DEFINE syntax or against REC or against NAMED-LAMBDA or
against NIL or against the behavior of EQ? on procedures or
against hexadecimal notation...

Dan Friedman had some very reasonable things to say about the
importance of simplicity and elegance, particularly with regard
to ease of implementation by students.  My answer is that
students should implement "Essential Scheme" instead of worrying
about how to get ASIN to work with complex numbers.  Essential
Scheme does not have internal definitions, and it is perfectly
all right to use an initial environment in which all variables
are bound and to implement DEFINE as assignment.

I must admit that Essential Scheme is a more elegant language than
full Scheme.

I second Bill Rozas's objections to MAKE-LOCAL-VARIABLE as a procedure
for performing incremental definitions.

Let us seek peace,
William Clinger

----------------------------------------------------------------
[Because of one mailer error, the local postmaster has suggested
that people send me mail at willc@tekchips.tek.csnet instead of
at willc%tekchips@tektronix.csnet, which had worked fine until
now.  If one doesn't work, please try the other.]