Can we standardize Scheme without killing it?

[Hal Abelson <HAL@AI.AI.MIT.EDU>]

Like David Bartley and Norman Adams, I've decided to unenthusiatically
support standardizing Scheme through IEEE -- provided we can do it
with proper precautions (see below).

The reason is not so much to "get Scheme out from under the shadow of
Common Lisp", as someone (I forget who) wrote to this list.  Rather, I
expect that as Scheme becomes more widely used, there will be
increasing pressure to standardize it.  And I am sure that as time
goes on, it will be increasingly difficult to standardize it in "the
right spirit."  Already, at our preevious R*S meeting, Scheme design
had become too much of a political process rather than a technical
one.  People had begun to see themselves not as individual language
designers, but as representatives of various constituencies of Scheme
users.  This can only get worse as time goes on.  So let's face the
issue now.  My fear is that it is already too late to avoid the politics.

I want to make a couple of suggestions

1) We meet very soon to decide whether we want to go ahead with
standardization, and if so, to figure out how to go about this.  I
think that this meeting should not talk about technical issues.

2) However the politics goes, the technical content of the first
Scheme standard should be what we have already agreed upon in R*S with
the possible exception of correcting obvious blunders.  I appreciate
Guy Steele's sentiment that we pass a rule saying that each person can
nominate at most one feature to be included.  But I think that this is
one feature too many.  (Guy's suggested REDUCE, which I think is a
wonderful thing, can be put in the Yellow Pages.)  In general I would
like to see a VERY conservative and VERY minimal standard.

3) My biggest worry about standardizing Scheme is my belief that
language design ought to be an evolutionary process guided by those
people with the best ideas at the moment, as worked out in research
papers and in implementations.  It should not be a political process
in which things are done by some offical set of empowered
representatives (whether empowered by ANSII, ISO, IEEE, God, or
whomever).  That sort of approach stultifies research by making people
feel as if they need to go to some "official body" to get their ideas
seriously considered.

I am currently refereeing papers submitted to the 1988 Lisp and
Functional Programming Conference.  If I simply count what Lisp
dialects people are writing about, then in 150 papers I have seen so
far, there are as many papers specifically about Scheme as there are
about Common Lisp.  If I ignore papers of the form "I have implemented
a neat program in Lisp" and restrict to papers that are proposing
serious language extensions or investigations of semantics, then there
are about a dozen of these about Scheme and only two or three about
Common Lisp.  I assume that some of this is because Scheme is a
cleaner language than Common Lisp.  But I can't help thinking that
another reason is that any serious researcher would think it a waste
of time to work on an extension to Common Lisp unless he is one of the
"duly constituted representiatives" of the Common Lisp Community.

To put it another way, standardizing something is a good way to shut
off research in it.  To my mind, much of the reason that Lisp is still
around after 30 years is that it never was standardized and so was
able to evolve in an informal way.

I think that Common Lisp is well on its way to being a dead language,
and I don't want the same thing to happen to Scheme.  But it's going
to be hard to resist.  Whatever group gets the power to make Scheme
"official" is going to be tempted to "satisfy the needs of all those
Scheme users out in the world" by making the standard more and more
complete and by arrogating more and more of the design process to
themselves.  And they will do this with the best possible motives.
For example, I am very impressed with the work of Bobrow, Kiczales,
Gabriel, etc. in designing CLOS.  But I think it is wrong for them to
do this under the auspices of X3.  One result is that the ONLY paper I
have seen so far about objects in Common Lisp submitted to the L&FP
conference this year is by members of the CLOS subcommittee.

So I think we need to give some serious thought to setting up a Scheme
standardization process that will be immune to this kind of
temptation.  For example, we might decide that extensions to the
Scheme standard will be adopted only in conjuction with some academic
conference (such as L&FP) and only after "the research community" is
satisifed that the issues have been fully explored and that some
concensus (NOT a vote) has been attained.  I would like to hear
suggestions from Clyde Camp on whether such a thing would be
compatible with IEEE (or ANSII or ISO) standards policies.

In addition, I would like us to include specific language in the
Scheme standard that puts the standardization effort in this light.
Here are some suggested paragraphs.  I am happy to have someone else
edit them and make changes, but I do want to include some such words
near the beginning of the report:

	  --------------------------------------------------
	       SUGGESTED PARAGRAPH FOR SCHEME STANDARD

Throughout its thirty-year life, Lisp has continually adapted to
encompass changing ideas about programming-language design.
Specifying a standard for Scheme is intended to encourage the
continued evolution of Lisp dialects by identifying a coherent set of
constructs that is large enough to support the implementation of
substantial Lisp programs, but also small enough to admit significant
extensions and alternate approaches to language design.  For example,
the standard does not mandate the inclusion in Scheme of large run-time
libraries, particular user interfaces, or complex interactions with
external operating systems, although practical Scheme implementations
ordinarily provide such features.

In particular, there are important linguistic design issues that are
not discussed in the Scheme standard {\em precisely because} Scheme
has sparked fruitful new approaches in these areas, and the authors of
this report do not wish to discourage the further development of good
ideas by taking a position on issues under active investigation.  Some
of these issues are:

Macros: The scope of identifiers in macros has traditionally been
problematic for Lisp.  Scheme's adoption of lexical scoping and a
single namespace for identifiers has stimulated the development of
macro-expansion techniquies that are more elegant and robust than
those appearing in other Lisp dialects.  Although this report does not
specify a macro-definition facility, most popular Scheme
implementations allow users to define macros.  The research literature
[ references ....] contains numerous discussions of macro definition
in Scheme.

Packaging: Scheme's uniform naming conventions permit ordinary lexical
environments (in some Scheme implementations) or slight modifications
of these (in other implementations) to provide poerful support for
programming-in-the-large.  This obviates the need for special-purpose
naming mechanisms (such as multiple obarrays) as adopted by other Lisp
dialects.  References [.......]  provide discussions of techniques for
packaging and module definition in Scheme.

Object-oriented programming: Scheme unadorned is nearly an
object-oriented language. [JAR and Adams: I hope you don't object to
my snarfing the first sentence of your paper.  It's a wonderful
sentence.]  With simple extensions (or even simple syntactic
conventions) Scheme becomes a powerful foundation for implementing a
panoply of object systems, with little of the conceptual baggage
adopted by other Lisp dialects.  See [refs .......] for examples.

[feel free to add more examples of Scheme's wonderfulness and your
current research: parallelism, continuations, logic variables, type
inferencing, ...]

The authors of this report hope that future revisions of the Scheme
standard will be sensitive to the fact that good ideas need time to
mature, and that exploration can often be stifled by the premature
adoption of standards.

	  --------------------------------------------------

-- Hal