Policy on change-making

[Jonathan A Rees <JAR@AI.AI.MIT.EDU>]

A number of suggestions for incompatible changes are currently on the
floor.  Before I start polling y'all about these various questions
(mostly removals), I would like to see if we can reach concensus on what
our policy should be for making such incompatible changes.  I think the
policy we adopt will bear on the changes we decide we want to make.
Questions that should be answered:

- How radical ought we to be?  That is, how important is compatibility with
last summer's report?

- Given that there will be incompatible changes, how should these be
indicated in the report?  Should I clutter the main text with little
notes; should I make a list of all the changes; if I make such a list,
where should it appear --- in the "notes" section, in the introduction,
somplace else?    Should the list include rationales

I guess my current bias is either to omit the list entirely or relegate
it to the notes section, in pursuit of a "crisper" [Dan Friedman's word]
document.  However, I again have nothing at stake, and don't care too
much, so people with real implementations should speak up.

Changes and removals (as opposed to clarifications or extensions) so far
agreed upon include the omission of the "object table" chapter, the
omission of all the #!foo constants, and the change in meaning of
(define (foo ...) ...)  [from using named-lambda to using lambda].  We
have already decided on some others, and may decide on others still, in
the coming weeks.

What other documents do:  The Revised Report on Scheme has pretty
thorough notes about how the language changed, with complete rationales.
The revised Algol 60 report merely enumerates, in a footnote, the
section numbers of sections that were changed at the 1962 conference.
The Algol 68 report has a comparison with Algol 60 (3 pages) as part of
its introduction, and the Revised Algol 68 report also has a comparison
with the non-revised Algol 68 report (4 pages).


Jonathan