[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
* I feel VERY STRONGLY that the lisp package should have only those
symbols defined in CLTL.
Here are some examples of problems I have had with Common Lisps in which
this wasn't true, (I do not mean to point fingers, I am just trying to
use concrete examples):
In an early version of Lucid Lisp memq was in the lisp package. It was
also a special function so that when PCL redefined it as a macro the
lisp got a bad headache.
On the Explorer string-append is defined in the lisp package. When you
load pcl is says "Warning... redefining string append, OK?" You say
yes, but then the editor breaks because they have extended string-append
to do some special stuff for the editor.
I KCL there are so many extra symbols in the lisp package that its easy
to use one of them without knowing it.
* make-package should inherit from lisp.
* I see no reason to specify the name of the package where people should
put their extensions. Extensions go in lots of different packages based
upon their nature, it would be cumbersome to have to decide if a
particular function deserves to be a "common Lisp extension" and should
be movce to the extensions package. Hmm should
zwei:with-output-to-buffer be in the extensions package.
In order for a programmer to make use of the extensions that a given
implementation offers they are going to have to spend enough time
reading about those extensions and interfacing them to their program
that the time it will take them to type a few IMPORTs or use-packages
will be insignificant. But someone who tries real hard to make a
program that really is portable should have as much of a chance at
wining as possible and extra symbols in the Lisp package get in the way.