[Openmcl-devel] Package locks?

[Peter Seibel]

Gary Byers <gb at clozure.com> writes:

> On Tue, 30 Mar 2004, Peter Seibel wrote:
>
>> Does OpenMCL have anything like Allegro's or CMUCL's package
>> locking? I.e. something to prevent code outside a package from
>> mucking with the definitions attached to symbols in the package?
>
> No.  At first glance, the idea seems wrong (or maybe more accurately
> half-right), but that's not an opinion that's based on actually having
> used them (or having thought about the idea for more than a few minutes.)

I suspect you're right. Or half-right. ;-) That is, package locks are
by no means a full solution to all the possible information-hiding and
keep-other-folks-from-breaking-my-code-from-the-outside problems that
one might like to solve. That said, they do provide an answer to the
seemingly reasonable question: how do I keep someone who USE-PACKAGE'd
my package from inadvertently stomping on a definitions that I care
about that happens to be on an exported symbol.

My perspective is as someone writing a book about Common Lisp; it's a
bit icky to have to explain that if you :use or USE-PACKAGE a package
and do a (defun foo ...) not realizing that FOO was exported by that
package you may have just clobbered that packages own function
definition. If I could say, "yes this problem exists in pure Common
Lisp but all implementations provide a package locking mechanism to
prevent it", that'd be better than "some implementations provide ...
in others you'd better be *very* careful". (Better yet would be "this
is a problem in pure ANSI CL but all the implementations implement the
layered standard FOO-PACKAGE-LOCKS so we can lock a package by saying
...". But that's a dream I don't expect ever to see come true.)

> That's mostly based on the observation that packages were the wrong
> way to enforce modularity in the first place (they also happen to be
> the primary way of doing so in CL ...), and that extending a bad way
> of enforcing modularity doesn't -sound- like the right thing.

I agree it's not The Right Thing. But I also think in this case Worse
*Is* Better. I.e. I'd rather have a partial solution, especially as
other implementations have already gone down this path.

> It's certainly possible that people would find them more useful in
> practice than they appear to me to be in theory.

As to their utility, I notice that OpenMCL *does* prevent me from
redefining CL:CAR. It seems to me that that's valuable. And it I don't
see why the system code should be the only one to be able to protect
itself. (Indeed, it may need it less than any other code because
people actually could be expected to learn what symbols are exported
by the COMMON-LISP package.)

-Peter

-- 
Peter Seibel                                      peter at javamonkey.com

         Lisp is the red pill. -- John Fraser, comp.lang.lisp