Full Specification

[cph@kleph.AI.MIT.EDU (Chris Hanson)]

   Date: Mon, 13 Jun 88 19:29:24 PDT
   From: Pavel.pa@Xerox.COM

   You say ``one really expects the definitions in a body to be
   accomplished in order''.  I don't.

   Requiring the implementation of internal defines to signal an error if
   <undefined> is referenced is quite possibly too expensive for many
   applications.  In addition, I dislike the notion of encouraging people
   to write series of internal defines that are sensitive to evaluation
   order.  It goes against what I consider to be the clean and readable
   purpose of such defines: binding local procedures.

Hear, hear!  Internal defines, just like `letrec', should be used ONLY
when the value is something that can possibly need mutual recursion.
In other words: lambda expressions and `delay' expressions.  In both
those cases there is no order of evaluation dependendence.
Defining an order implies that internal definitions can and should be
used for other values as well -- a terrible idea.

   A significant source of first-level optimization is the lack of a
   defined argument-evaluation order in the language.

Again, I agree.  MIT's compiler takes advantage of this to produce
significantly better code than it could otherwise -- and we intend to
build more optimizations in the future that depend on this
underspecification.

I think it is a good idea to understand why we need
underspecification, and where.  But full specification has some
serious problems:

1. It ties the hands of the implementer.  My comments on order of
argument evaluation are an example.  Another: MIT Scheme foolishly
allowed the value of `set!' to become defined -- without ever saying
it in print anywhere -- thus requiring the compiler to generate code
for that value whenever it couldn't prove that the value was not used.
I'm seriously considering changing that behavior despite the fact that
some people depend on it.

2. Underspecification is useful.  My comments on internal definitions
are an example.  Here we are trying to encourage a style, without
requiring all implementations to enforce it.  Full specification in
this case would DISCOURAGE that style, while encouraging a different
one.

3. Full specification is a never ending game.  When have we finished
specifying everything?  People will be forever noticing new details
that we have missed and forcing us to specify some behavior for them.
In fact, most of those details are uninteresting.

In contrast, underspecification is automatic.  By overlooking some
behavior, we have "underspecified" it.  This is appropriate, since the
kind of thing that is likely to be overlooked is precisely the thing
least interesting to specify.