[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Keyword extensions to Compile
- To: common-lisp@su-ai.ARPA
- Subject: Re: Keyword extensions to Compile
- From: hpfclp!diamant@hplabs.ARPA
- Date: Wed, 21 May 86 14:03:49 pdt
From: "Scott E. Fahlman" <hplabs!Fahlman@C.CS.CMU.EDU>
Put another way, I think that every implementation should pick some other
package and put all their extensions on that package and leave the LISP
package pure. We've hashed this one out at length. If someone doesn't
think that there was overwhelming concensus that this was the right
thing, I'd like to hear from them.
I don't think that consensus was reached on this. There was mail on
both sides, and in the absence of a decision procedure, the discussion
eventually petered out. This will certainly be among the issues we want
to get a final decision on as the ANSI spec is developed.
Since you ask, my own view is (still) that each implementation will want
to provide a default Lisp environment for their users, including all of
Common Lisp plus some implementation-specific extensions, and that this
is what should live in the LISP package and be inherited by default in
other packages such as USER. It is certainly a good idea to have some
other package that is pure Common Lisp, but this should not be the
default environment for users. The mix of things in the default
environment should be a local option.
The problem with making the default environment the extended one is that it
is IMPOSSIBLE to write portable programs! If implementation X makes an
incompatible extension to COMPILE, and I want the CL-only environment so
I can use the CLtL version of COMPILE, I must say something like:
(use-package 'cl-only)) ; or some other non-standard package name
I realize that someday we may agree on the name of the this other package, but
that isn't an upward compatible change. It requires everyone trying to write
portable code based on the first edition of CLtL to change their code. The
piece of code above has made the inherently portable program no longer
portable (since if I didn't know about implementation X, I couldn't have
written it to run on implementation X).
If, on the other hand, the lisp package (and the default environment) contained
no extensions, you wouldn't need to say anything for portable programs, and
for programs specific to that environment, you would say:
#+X (use-package 'extensions) ; or whatever it is called.
It is much preferable to require the use of *features* in inherently
non-portable code than in portable code that has been made non-portable because
the Lisp system comes up in a non-portable mode.