[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Scheme Standardization




========================================================================
= IT IS MUCH MORE DIFFICULT TO GIVE BIRTH TO SOMETHING THAN TO KILL IT = 
========================================================================


I've watched the RRRS-AUTHORS mail for the last couple of weeks with
interest and feel it is time to respond to the issues raised on
standardization and clear up a few apparent misconceptions.

For those of you who do not know me, my name is Clyde Camp and I work
for the Computer Science Center of Texas Instruments.  I've been
involved in standards work both inside TI and outside for about 15
years.  I'm also the chair of the Microprocessor Standards Committee
(MSC), having been vice-chair for a year and secretary for three years
preceding that.

Before I go any further, let me point out that in any discipline there
are always horror stories of things gone wrong or difficulties
encountered.  The standards world is no different and the few horror
stories are widely circulated while the many successes go largely
un-noticed by all except those directly involved.  It is also
interesting to note that, historically, the more severe problems have
been due to hesitation or waiting too long to do something rather than
starting things too quickly.  One of the major reasons for the various
committees is to isolate the technical work of the working group members
from most of the "hassle" of the standardization process itself.  Only
the chair NEED worry about that (although anyone else who is really
interested is welcome to attend anything.)

The rest of this is broken into three parts:

    1) A history of the Scheme standard proposal mentioned by Chris
        Haynes. 
    2) A response to the replies he had received as of January 4th. 
    3) A set of recommendations which the readers should consider.
        (transmitted separately)

In the interests of time I have not attempted to explain the sequential
steps involved in standardization, except as they directly apply.  The
process is rather well outlined in a pair of articles by Dr.  Michael
Smolin in the August-87 issue of IEEE MICRO (pages 82-83) and in the
October-87 issue (pp 92-94).   

If any of you wish to contact me directly, I can be reached at (214)
995-0407 (beware the answering machine) or at camp%TI-CSL@CSNET-RELAY.



                        ***HISTORY***

The current attempt to bring about a Scheme standard was originally
initiated by me about the middle of last year and was based on the
following: 

  1) Scheme is an ideal language for general symbolic processing
  2) It is significantly better suited for embedded applications and
      small systems than Common Lisp
  3) It is an ideal educational/instructional language 
  4) There were at least three commercial implementations (all mostly
      alike, but with significant differences)
  5) There seemed to be a growing ground swell of users who liked the
      language (brought about in no small part by the Abelson/Sussman
      'Bible') 
  6) There was already a group in existence who had generated a working
      'specification' for the language, who represented a reasonable mix
      of theorists, users and implementors and who were eminently
      qualified.  This existing 'specification' is already better
      than some existing standards.
  7) I didn't want to see the Common Lisp standardization mess (due in a
      large part to waiting too long before starting) repeated with
      Scheme. I wanted it to be a pro-active standard rather than a
      retro-active one.
  8) I felt that the IEEE/CS was the best way to get such a standard
      developed. 

My personal belief is that Scheme stands a very good chance of being the
symbolic and arithmetic language-of-choice in the long-term (5-10
years).  But I don't believe that it can be so without at least
partially leaving its current academic environment and finding a
sponsoring organization such as the IEEE or ACM - there will be too many
external pressures (user, industry, government).

At that time I sent Jonathan Rees, David Bartley and a few others a
short message on the pros/cons of standardization and suggested that the
topic be brought up at the June-1987 RRRS meeting.  Based on David's
report back to me that it had been raised and quickly dismissed, I took
the easy path of not pursuing the issue any further (and have even lost
the text of the message I sent.)

In early December, 1987, Jim Flournoy (with the Computer Society
Standards Activity Board) independently recognized that it might be an
appropriate time to begin a Scheme standardization effort.  He called me
and asked for names of people who I thought might be willing to chair
such an activity.  I opened up the RRRS red-book and gave him the names
of the people who were foolish enough to have their names printed on the
first page.  When he reported back that Chris Haynes and Will Clinger
had agreed to consider being chair and secretary respectively, I called
both back in mid-December and, after several long discussions, conned
them into considering positions of chair and vice-chair instead.

Will and Chris then began polling the Scheme community for Interest,
Disinterest, Non interest.  The jury is still out.

Without going into all the gory details, we tried to get things lined up
to have Chris or Will present at the January MSC meeting (or me pitch
their presentation).  The January meeting was important because it was
the day before the annual ANSI Standards Project Authorization Review
Committee (SPARC) meeting.  It would have been ideal if this could have
been worked out since SPARC is the committee which reviews submissions
to ANSI by X3 and IEEE.  For various reasons, this time frame turned out
to be too short for everybody to get their act together, so I would like
to try for the the next MSC meeting in March or the one in May.

One of the primary reasons for pushing on this is to get a head start on
all the administrative time lags built into the process.

For those of you who are by this time thinking "All that crap is the
reason I didn't want to get involved with the damn standards activity to
begin with" the good news is that none of the above should affect what
the working group is doing or when it meets.  One of the major reasons
for the various committees is to isolate the technical work of the
working group (WG) members from most of the administrative process of
the standardization business itself.  Only the chair NEED worry about
that although anyone else who is really interested is welcome to attend
anything.


                    ***** RESPONSE ****

CHRIS HAYNES:

A excellent (balanced) summary. There is little I can add other than to
correct a few minor points (which may have been due to a
mis-communication on my part to begin with).

With respect to working group attendance and 'voting' rights, there are
NO formal procedural requirements at the working group level.  The WG
Chair is pretty much free to run things the way he wants.  Although
there are some informal guidelines that will be recommended, the CS
Policies and Procedures manual states merely that the chair of the
working group is responsible for developing the document.  Again, the
reason for this is to keep the working group as free from the
administrative details as it wishes to be.  There are no requirements
for meeting frequency or place or attendance for example.  While the
Chair is required to be a CS or IEEE member, there is no such
requirement on any of the other WG members.

As Chris pointed out, trial-use standards are reviewed every two years
and recommended for full use, withdrawal or revision.  Full-use
standards come up for review every five years for reconfirmation,
withdrawal or revision.  So a 'STANDARD' is not cast in concrete for all
time.  

The extensive use of E-mail net to development a standard is a new (to
the MSC) methodology, but one which I encourage.  Although non-net
interested parties must also be accommodated, the Chair can probably
handle this is by keeping a mailing list of those entities and sending
them hard copies of the net traffic at periodic intervals or as
necessary.  The IEEE secretariat can be used to take care of
reproduction and mailing if necessary (all she needs is one copy and a
mailing list) but we have a limited budget and prefer that the WG work
this out if possible.

DICK GABRIEL:

(1-3) There are some tough arguments and questions here but many of them
are between basic philosophical issues which are akin to arguing the
advantages/disadvantages of big-endian vs.  little-endian.  Dick's
comments about splitting up (or not) Scheme and Common Lisp were
interesting because I've wondered as well about the possibility of a
family of symbolic processing languages.  The scope of something like
this is scary and the initial reaction is probably "No way, Jose -
Impossible".  But those of you who think pulling together (apparently)
radically different things under one umbrella is an impossible task
should talk to Maurice Graube who chairs the 802 networking standard (a
success story if ever there was one.)

I fully agree with Dick's statement that the work gets done by small
groups which are self motivated but disagree with his conclusion that
nothing will change other than for the worse.  A properly run standards
working group does help motivation, discipline and visibility - it
happens more often than not.  Common Lisp is, unfortunately, an example
of 'not'.

(4-6) The answer to all three of these is basically "It's possible, but
only if you let it." I think it's far less likely that any of these
fears will be realized if the RRRS cadre is in the driver's seat. A
scenario that bothers me more is "company X" pushing its implementation
of Scheme as THE correct and only implementation.  

(7 - the first one) RPG is right except for the last paragraph, which
again is my fault.  With exception of the actual working groups, voting
rights at each committee level are xxxx + "appointment by the chair with
concurrance of the next higher chair" where xxxx is formally specified
in the CS Policies and Procedures manual.  The working groups have no
such restrictions and although the recommendation is that some generally
uniform policy be maintained, it is always the Chair's perogative to
issue voting rights (for example to individuals who can't personally
attend for some reason but who are obviously valuable contributors) or
to remove them (for example to allow company-X only one vote to prevent
it from sending 300 people to swing the standard to meet its product) or
to not vote at all and develop the specification by some other means of
consensus.  

With respect to lawsuits, the IEEE provides protection to the WG from
such things to some extent.  While such an issue has never come up and
the degree or capability to which the IEEE would defend such a suit is
unknown, members are certainly better protected than a non-sponsored
group.

(7 - the right thing?) Perhaps this effort?


RAMSDELL:
=========

These are largely tactical decisions which can be made if and when a WG
is formed.  Again, standards can be added to.  The current RRRS approach
of essential vs non-essential may be entirely appropriate. Similar
things have been done on  hardware standards.  I think I would advise
against trying to include parallelism at this stage.


ALAN BAWDEN:
============

I don't believe in the "First Strike" theory either, although I do
wonder why it keeps happening.  Seriously, it has happened but while the
possibility exists, I suspect that in this particular case the scheme
community is sufficiently close-knit that it would be aware of such an
effort and might be able to insert the red-book as a proposed draft even
if it should occur.  It is always easier and more efficient to start
with something which is at least partially acceptable than to start all
over from scratch - if for no other reason than the job of physically
entering the text.


CHRIS HANSON:
===============

What?!?!?!? 

I'm one of those "IEEE people" you refer to (as are four of the 17 RRRS
authors) and I will certainly take issue with anyone who tells me I have
no committment to the language.  It's BECAUSE I have a committment to
the language that I'm taking the effort to try and get this effort
going.  If you have legitimate arguments on either side then voice them
by all means, but please do so without rancor.


KENT PITMAN:
============

I hope the previous megawords clear up some of your confusion with
regard to who is doing what and why.  

You are somewhat right in your belief that the larger a group becomes,
the less useful work it can do.  I say somewhat because it depends on
the absolute size - I'll contend that three can do more than one but
certainly 20 can do more than 200.  However, as I've said before, the
entire standards organization is not involved here - only those that are
in your working group.  Even this could become large although only a few
do "useful work".  Using the MSC itself as an example, the mailing list
is about 200, however only 30 or so are what I would call participating.
The rest are there primarily for info although they may inject comments
(sometimes even useful ones!) now and then.  It may help to think about
it like CS-NET.  How many read or have access to RRRS-AUTHORS vs how many
actually contribute? 

Ceasing design work to initiate a standard is not a requirement.  If it
were, there would be far fewer standards around.  It is entirely
possible to be in 100% compliance with a standard and yet extend it
provided the extensions don't alter things you've done before.  The goal
of a standard is most definitely NOT to "maximize the number of people
to whom it appeals at the cost of its values" although where to draaw
the line is often difficult to decide.

===================

My recommendations on where to proceed from here are being transmitted
in a separate message.

REgards, Clyde