[HARLEQUIN][Common Lisp HyperSpec (TM)] [Previous][Up][Next]



References: X3J13 committee and sub-committee meetings

Category: Policy

Edit history: 12-DEC-88, Version 1 by Chapman

20-DEC-88, Version 2 by Chapman

9-JAN-89, Version 3 by Chapman

Problem Description:

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

X3J13 meeting).

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

future standards;

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.

It's not

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.

Current Practice:

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.

Adoption Cost:



This policy will provide a basis for future X3J13 decisions.

Conversion Cost:






"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."

[Starting Points][Contents][Index][Symbols][Glossary][Issues]
Copyright 1996, The Harlequin Group Limited. All Rights Reserved.