[comp.lang.scheme] An open appeal to the Scheme standards committee

robertj@autodesk.com (Young Rob Jellinghaus) (05/29/91)

I am posting this appeal at the request of Marc Le Brun.  Comments or
responses should be sent to mlb@autodesk.com or posted to this
newsgroup.


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


		An Open Appeal to the Scheme Standard Committee


Dear Colleagues --


We would like you to know that we enthusiastically support the efforts
to standardize Scheme and thereby promote its use within the greater
computing community.

In fact, we have made substantial investments incorporating Scheme,
even though the standard is still developing, into plans for potential
future commercial products, internal R&D efforts and educational
activities.  Some of our reasons include:

  * the well-known benefits of "symbolic computing" (as a member of the
    "Lisp family" of languages)

  * "exceptionally clear and simple semantics"  [R^3RS]

  * support for a "wide variety of programming paradigms"  [R^3RS]

  * amenability to small, lightweight yet efficient and powerful
    implementations

  * ease of incorporation, embedding or tight coupling with other
    programming systems, ranging from C++ to applications

  * congeniality towards extensions

  * standardization

We feel that because of these and other factors Scheme may have a
bright future indeed, advancing the overall level of sophistication of
computing practice.  We believe that it is currently the technically
best and pragmatically strongest contender to become either the
primary or extension language of choice for many types of
applications.

Recently, however, we have become worried about an apparent trend in
the standardization process.  Although we do not have full information
about the progress of the standard, we are under the impression that
large, complex or portentious language extensions are being proposed
and considered.  If adopted into the standard, they may significantly
burden Scheme implementations.  At the least some are very difficult
to analyze with confidence.  (Eg multiple return values, macro
facilities).

To address this concern we would like to propose that factorably
different aspects of Scheme be the subject of independent (but
possibly contingent) standards.  In particular, we would like to see
the specifications of additional useful-but-not-vital functionality be
segregated from the specification of the core language (perhaps as
standard libraries, or as optional subsections of the standard).

This approach would provide the benefits of standardization while
promoting experimentation and extension.  It merely carries the
principles of modularity common in programming practice over into the
language design itself.  It avoids overloading the elegant and proven
central parts of Scheme with extra baggage that will detract from the
very economy which makes it so attractive in the first place.

We understand and sympathize with the pragmatic motivations that drive
a language design to become ever more fully-featured.  However we
strongly feel that Common Lisp already provides an excellent "large"
symbolic computing standard.  Greater benefit will accrue to all if
the two languages evolve to serve different niches, rather than
competing with each other and leaving the field Scheme currently
addresses to less capable and less elegant contending languages.

To paraphrase R^3RS, "programming languages should not be designed by
piling feature on top of feature."  We endorse the spirit of that
report, and note that it is dedicated to the memory of Algol 60, not
Algol 68.

Please keep Scheme clean and lean.


				Marc Le Brun
				Director, Advanced Technology
				Autodesk Inc
			    
				Mark Miller
				Co-Architect
				Xanadu Operating Company
				Co-Director
				Agorics Project
				George Mason University

				Rudy Rucker
				Professor
				Department of Mathematics and Computer Science
				San Jose State University
			    
				Norm Hardy
				Senior Scientist
				Key Logic Inc

				Eric Benson
				Principal Scientist
				Lucid Inc


(The above would also like to acknowledge contributions to this
statement from Rick Mascitti, Rob Jellinghaus, Paul Baclaski and Dean
Tribble.)


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


--
Rob Jellinghaus                 | "Next time you see a lie being spread or
Autodesk, Inc.                  |  a bad decision being made out of sheer
robertj@Autodesk.COM            |  ignorance, pause, and think of hypertext."
{decwrl,uunet}!autodesk!robertj |    -- K. Eric Drexler, _Engines of Creation_

kend@data.UUCP (Ken Dickey) (05/29/91)

robertj@autodesk.com (Young Rob Jellinghaus) writes:

>In fact, we have made substantial investments incorporating Scheme,
>even though the standard is still developing, ...

>Recently, however, we have become worried about an apparent trend in
>the standardization process.  Although we do not have full information
>about the progress of the standard, we are under the impression that
>large, complex or portentious language extensions are being proposed
>and considered.  If adopted into the standard, they may significantly
>burden Scheme implementations.  At the least some are very difficult
>to analyze with confidence.  (Eg multiple return values, macro
>facilities).

There is an "Standard for the Scheme Programming Language" which is
available from the IEEE (I believe the phone # is 201-562-3800).  This
is the result of an IEEE standards group which is now dissolved.  It
was dissolved when the standard was accepted.

There is also a Scheme Authors' Group which has been responsible for
the R^NRS (the Revised Reports).  The next report--R4RS--is very close
to the IEEE standard but with the addition of macros.

The IEEE standard is very conservative.  The R^NRS reports are
considered "experimental", but are in fact very conservative.
Historically, no language feature has gotten into R^NRS except by
complete concensus by the Scheme community--a feat difficult to
achieve.  In fact no language feature I am aware of has been proposed
by the authors' group without experimental implementation(s) and usage
being done first.

While language features are continually being proposed and discussed,
this in fact has very little chance of a near-term impact on any
Scheme standard.  So, don't worry.  


-Ken Dickey				kend@data.uucp