Considerations wrt official standardization

[Chris Haynes <chaynes@sunfish.cs.indiana.edu>]

An IEEE standards must be revised, reaffirmed, or revoked every 2 to 5
years. I expect it would be unwise to revive the IEEE standardization
process for at least a year, with two or more years seeming most
appropriate. But we must anticipate that this will happen, and it could
happen soon. (The IEEE Scheme standard is now 1 1/2 years old). 

Whenever this happens, the public nature of official standardization
efforts and their visibility within industry means that participation by
a variety of relatively new industrial users should be anticipated. Such
users frequently suggest that Scheme be extended to include features such
as multiple values, modules, and exception handlers. If such additions
are appropriate, it would be best if we can agree on them as elements of
R5RS, so that they may be publicized and experience with them gained
before they are considered in a more formal standardization process. On
the other hand, if some additions are deemed inappropriate, it is equally
important that arguments to this effect be documented so they will be
handy if these additions are proposed in the context of official
standardization. In general, I feel a language's design is not complete
until there are written rationales for those features of its design that
are perennially questioned, whether these features are inclusions or
conspicuous omissions.  Thus I agree with Jonathan that we should at
the very least assemble a crude, informal rationale document, and with Dick
that a polished, formal rationale document would be of even greater value
in this, and other, respects.

Do I recall properly that someone is maintaining an ftp directory of 
the current proposals for major additions to Scheme?  If so, where is 
it?  Unless it is obvious that the need for such additions can't be 
satisfied by loading code from a library, then such an argument should be 
included in the proposal.  Rationales for non-adoption of a proposal 
should also be collected in the same place.

The gentlemanly policy of unanimous agreement under which the revised
reports have so far been developed has, for the most part, served us
well. It was also quite fortunate that this proved compatible with the
first IEEE Scheme standard. Official standardization efforts must,
however, be designed to achieve broad consensus, not unanimity. This may
even mean majority-rule votes, though in the end decision making is not
nearly that straight-forward. For example, response is required to
substantive objections raised in negative ballots, and these responses
must be satisfactory to the committee that reviews the standardization
process prior to final approval.  

In any case, if proposals for which there is broad consensus are not
adopted by R5RS, we risk their being adopted in a revised IEEE standard
before adequate experience with them has been gained. It would be best if
official Scheme standards remained compatible with the current revised
report, but this is unlikely (and inappropriate) if the revised reports
become so conservative that they fail, without adequate technical 
justification, to satisfy important needs.  

It isn't clear to me how, if at all, the consensus procedure of the
report authors should be changed. It may be best if we can simply avoid
this meta issue and get on with substantive business. We must all
understand, however, the potential cost of failure to reach agreement on
features for which there is wide-spread consensus and a strong perceived
need. Perhaps this understanding will prompt enough gentlemanly
abstentions for the needs of the Scheme community to be met under our
existing unanimity constraint. If not, we will have to find another way
of being sufficiently, but not excessively, constrained.