package locking
Sam Steingold
E.g., suppose you have a package FOO and you want to lock it:
(setf (package-lock FOO) t)
what actions should trigger a (continuable) error?
(intern "ZOT" "FOO") ; fine in LispWorks and ACL
(export FOO::ZOT "FOO") ; fine in LispWorks, error in ACL
(defun FOO:ZOT () t) ; error in LispWorks & ACL
(defvar FOO:ZOT t) ; fine in LispWorks and ACL
what do you think?
what is your experience?
Thanks.
--
Sam Steingold (http://www.podval.org/~sds)
Keep Jerusalem united! <http://www.onejerusalem.org/Petition.asp>
Read, think and remember! <http://www.iris.org.il> <http://www.memri.org/>
(lisp programmers do it better)
Steven M. Haflich
Sam Steingold wrote:
>
> what level of package locking is considered useful?
>
> E.g., suppose you have a package FOO and you want to lock it:
> (setf (package-lock FOO) t)
>
> what actions should trigger a (continuable) error?
>
> (intern "ZOT" "FOO") ; fine in LispWorks and ACL
>
> (export FOO::ZOT "FOO") ; fine in LispWorks, error in ACL
>
> (defun FOO:ZOT () t) ; error in LispWorks & ACL
>
> (defvar FOO:ZOT t) ; fine in LispWorks and ACL
I implemented the first version of package locking in ACL
back around 1990. The reason it suddenly became a good idea
was that I had very recently reimplemented the ACL stream
class as a standard-class more or less following the Gray
proposal. Until then, relatively little of the internals of
most Lisp implementations depended upon CLOS (the LMs being
obvious exceptions).
Now, beginner Lisp programmers somehow frequently first start
exploring object classes by defining one. Not an insignificant
number do something like the following in their initial
experiments:
(defstruct instance name color)
Think for a minute what this does. If you don't like thinking,
fire up your favorite CL implementation, turn off package
locking if necessary, and execute the form yourself. The less
foolish can just macroexpand the form instead.
The result, of course, is that the implementation becomes
completely broken and can't even cons up an error condition
or string-output-stream to try to report the failure because
it can't even cons up an error condition to report the failure
... recursive errors downwards into catatonic oblivion.
Other support benefits soon became evident. Sometimes a user
would inadvertently redefine a function, forgetting or not
knowing that the name was exported from CL or one of our
public packages. Having package locking would either prevent
obscure hard-to-debug errors from needing to be handled by
our support desk, or when they did (since package locking
silently records violations even when reporting is turned off)
would facilitate support response.
Now to get to your actual question. IMO, package locking should
be aggressive and strict. Strictness enhances the ability of
multiple independent software modules to live in the same image,
and this has become even more important over the years as
independently-written modules such as database interfaces, web
servers, and computational modules might all be combined into a
single application. The perfidious effect of package violations
is that, although the original implementor might combine modules
that don't conflict today, a later version of one or another
module might create conflicts. This sort of thing is very hard
for anyone other than the original implementor to determine and
correct, and hard even for the original implementor after a few
months.
Restrictions on makeing definitions on names are described in
the Packages chapter of ANSI CL and a more elaborate prescription
appears in the AMOP. The general notion, however, is that most
packages are logically "owned" by the implementor, and that no one
other than the implementor should make definitions on names in that
package.
The implication of the examples you provide is that package
locking is appropriate for definitions on names that are
already defined, but bothersome for names that are not otherwise
defined. For example, it is quite proper for the implementation
to complain if you try to defun cl:list because there already is
such a function defined. But it seems annoying to protest a
defun cl:class because while this symbol has a class/type
definition, it has no preexisting function binding in a conforming
ANSI implementation.
So let us assume that you are an expert, studious, experienced
Lisp guru. You know that there is no function binding for
cl:class and so feel free to define one for your own convenience
in your application. Surely there will be no problem, you think.
But then some other programmer working in some other module that
happens also to get loaded into your Lisp world, a programmer who
is inexperienced, unstudied, and unknowledgeable, steps on your
function by defing _his_ function on that same name. That
worthless fool sure will be causing you unnecessary grief.
You see, the package locking system could never be smart enough to
determine which implementor is the guru and which is the fool...
Erik Naggum
| You see, the package locking system could never be smart enough to
| determine which implementor is the guru and which is the fool...
I thought that was what the without-package-locks macro was for.
///
--
Steven M. Haflich
While the package locking system is not smart enough to tell a guru
from a fool, it is certainly smart enough not to trust a logical
statement of the form "I am not the fool."