References: X3J13 committee and sub-committee meetings
Edit history: 12-DEC-88, Version 1 by Chapman
20-DEC-88, Version 2 by Chapman
9-JAN-89, Version 3 by Chapman
When features of a language become outdated due to technology advances,
or unnecessary due to the addition of better features, should the old
features be deprecated from the language, or deleted outright?
Since there has never been a Common Lisp standard before, deprecation
is against a de-facto standard, which may or may not be appropriate.
Deletion, on the other hand, is cleaner, but may generate never-ending
discussion when the standard goes for public review (and even in the
In summary, there are two levels:
1) features in CLtL that are not present in ANSI Common Lisp 1989,
2) features in ANSI Common Lisp 1989 that will likely not be present in
and the issues are:
a) what features fit into which category
b) how should implementations deal with such features? how can programs be
written to avoid problems with such features?
Since Common Lisp has been used industrially, it is reasonable to
assume that any level 1 feature will be a cause for
at least some controversy. Therefore, this proposal suggests that
X3J13 put features categorized as level 1 in a separate package,
and retain features categorized as level 2 in the Lisp package, but
declare them deprecated in the standard.
The members of each level will be determined on a case-by-case basis by
the X3J13 committee.
The standard should contain information about deprecation since
the topic has been mentioned more than once in X3J13, and since
Common Lisp is such a large language.
unreasonable for a language the size of Lisp to get rid of the
never-used tools, but we don't want to generate years of discussion
over a relatively minor issue when the standard goes for public review.
Fortran successfully deprecated one constant. However, a proposal
submitted during its latest standardization effort that
suggested deleting old features in favor of new ones was
opposed vehemently. The Pascal committee is currently opposed
to deprecation, and the SPARC proposal suggests that
deprecation should be dictated by the marketplace.
This policy will provide a basis for future X3J13 decisions.
"I personally would argue for not including "deprecated" features in
the standard at all, because including them now will make it harder to
remove them later. My perception is that ANSI Common Lisp is turning
out to be a much different language than what is described in CLtL,
particularly if CLOS becomes a required part of the language. If,
with the benefit of hindsight and experience, we now realize that some
"features" described in CLtL were really "bugs", the time to remove
them is *before* they become cast in stone as part of ANSI Common
Lisp. I suspect that most implementors will continue to provide these
features as extensions anyway, as long as a substantial number of
their customers are still using them."
Perhaps most implementors will continue to provide the deleted features,
but they will do that also if they are deprecated. Since the only real
difference between the two is the amount of discussion one will generate
over the other (I think that worrying about future difficulty of getting
rid of the features is not a "real" difference yet), it seems that choosing
the route of least resistance in this case is the wisest course.
"For the most part, X3J13 hasn't been able to deal with
which features fit into which category until how the categories will
be divided has been resolved. In particular, there are a number of
features that we didn't want to remove from ANSI Common Lisp 1989 if
it would be awkward for implementations to continue to support them or
programs to continue to use them, but wanted to at least declare them
"obsolete". There's been some debate on whether CHAR-FONT, for
example , should be deleted before the standard is written, or declared
deprecated within the standard."