Releasing potentially confusing info to the CL community

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

[Common-Lisp removed; CL-Cleanup added.]

    Date: 31 Dec 87 16:34:23 PST (Thursday)
    From: masinter.PARC@Xerox.COM
    To: COMMON-LISP@SAIL.STANFORD.EDU

    There will probably be a letter ballot to X3J13 to confirm the cleanup items
    accepted by voice vote at the recent X3J13 meetings. I'd say that these changes
    would then has as much `official' status as anything.
    ...

Which is to say: "none". I would say that this is a misleading statement.
Our committee has no charter to legislate changes to CL as it exists now.
The committee which could do that has not met for two years. It was not even
clear whether it had the power to make changes when it did meet.

I'm firmly of the belief that people should not be encouraged to assume that
present-day CL is other than CLtL.  CLtL is a target that can be hit. If people
start randomizing some but not all dialects in a disorganized fashion to try to
take "cleanup" changes into effect, there will be even more chaos than there is
already. Some changes are not compatible. The others are only compatible if you
assume that all implementations are changed in lockstep; if some implementations
change and others do not, then porting code from changed implementations to
non-changed implementations may be expensive. Our current environmental impact
statements do not discuss this I-think-peculiar-and-undesirable situation.

I very very strongly believe that the chunking size of any information to the CL
community should be considerably larger (ie, something like a "draft proposed standard")
than these proposals -- never something trivially separable like this. Otherwise
you get into a non-linear situation where one CL implementation has informally made
changes A, B, and C and others have made changes C, D, and E and you can't compare
them. On the other hand, it is easy to compare CLtL to draft CL-88 or perhaps-not-draft
CL-90 because the changes will be sufficiently bundled that we can afford to give
them a name. I'm loathe to think that CL's will be identified by non-linear names
like CLtL+FLET-fix+...

Either that or it might work to number the decisions and say that if you implement
any cleanups, you must implement all the cleanups which precede it so that a single
revision number may be assigned to your implementation. I'd have to think more about
this if anyone wanted to pursue it.

-kmp