Re: Standardization

[Deutsch at PARC-MAXC]

Several assertions that have been made about Lisp standardization
contradict my experience with standardization and/or Lisp.

Re KMP: yes, it's true things don't always go the way a particular
individual wants.  But balance some amount of unhappiness /
inconvenience for some number of individuals against the incredible
amount of work required to keep one's programs running in a "moving
target" and/or do lots of niggling little edits (some of which may not
be mechanically detectable, e.g. if the semantics of some existing
function change in some subtle way).  I've seen this in Interlisp --
hardly any program of mine survives more than a year or two without
having to be edited.  I would expect things to be at least as bad in
the more volatile MIT environment.

The option of "freezing a system" is hardly ever realistic.  New
packages get written and people want to use them.  The outer
environment (operating system, etc.) changes; the language system has
to track them, and nobody wants to fix old versions.  Bugs get
discovered and fixed, but not retroactively.  I've seen this
phenomenon in every language system people have tried to fork off a
frozen version of.

Computer standards can accomplish a lot if enforced.  APL is a good
example. Algol is another.  Cobol is yet another.

Re GJC: unfortunately, everyone doing things "his own super-winning
standardized way" doesn't work either.  For several years I did my
Interlisp programming in a system which I had done modest extensions
and adaptations to.  I finally had to give it up, because none of the
programs I wrote could be combined with programs written by anyone
else (because they had all extended and/or adapted the system in their
own ways, some of which were incompatible with mine).  Arbitrary
compile-time evaluation and user-extensible compilers make this
problem much, much worse.

I personally favor an approach similar to that of the Utah group:
standardize a modest kernel of Lisp which all systems agree to
implement compatibly.  This allows people to write transportable
programs if they want to, and to balance the cost of transportability
(both between systems, and into future versions of their own system)
against whatever gains they get from using non-standardized features.
As we gain more experience, the size of the standardized kernel can
grow.