Re: [Sbcl-devel] package locks

Tobias C Rittweiler <tcr@...> writes:
> However, package locks work on a strict per-symbol
> basis which is way too coarse. So for example if I export
> a function named FOO, I want to prevent people from
> defining a function FOO, but they may well define a
> type FOO.
Consider two clients of your code, both of them using your package. The
point of package locks is that there's otherwise no way of preventing
their two mutually inconsistent definitions of the type FOO from
colliding. You might want to prevent people from defining a function
FOO, but third parties should not be encouraged to believe that defining
a type FOO in your package, usually by mistake, is a good idea. In
other words, I really don't think (given that the symbol is the unit of
visibility) that the per-symbol basis is too coarse.
Cheers,
Christophe

Thread view

SBCL's package locks were written to enforce CLHS 11.1.2.1.2.
Unfortunately I find those rules way too restrictive to
be able to use package locks for my own stuff.
Basically, I want package locks to prevent other people
redefining stuff they use from my packages. For instance,
to redefine a function, or a class, or a type.
However, package locks work on a strict per-symbol
basis which is way too coarse. So for example if I export
a function named FOO, I want to prevent people from
defining a function FOO, but they may well define a
type FOO.
Of course, 11.1.2.1.2-enforcing package-locks make
total sense for SBCL itself, not so much for package-locks
as an advertized implementation-extension.
How do the people at ITA deal with the problem of inadvertent
redefinition?
-T.

On Oct 25, 2010, at 11:37, Tobias C Rittweiler wrote:
> SBCL's package locks were written to enforce CLHS 11.1.2.1.2.
>
> Unfortunately I find those rules way too restrictive to
> be able to use package locks for my own stuff.
>
> Basically, I want package locks to prevent other people
> redefining stuff they use from my packages. For instance,
> to redefine a function, or a class, or a type.
>
> However, package locks work on a strict per-symbol
> basis which is way too coarse. So for example if I export
> a function named FOO, I want to prevent people from
> defining a function FOO, but they may well define a
> type FOO.
This is actually a good thing, for the same reason it is for CL
itself. It may not harm the operation of *your* package for a user of
YOUR:FOO to define a type named FOO (= YOUR:FOO), but if two users of
your package both define types FOO and are in the same lisp image
(e.g. application loads A and B and both use YOURLIBRARY), then they
will interfere. The CL rules and SBCL package locks protect your users
against conflicting with each other later.
--
Kevin Reid <http://switchb.org/kpreid/&gt;

Tobias C Rittweiler <tcr@...> writes:
> However, package locks work on a strict per-symbol
> basis which is way too coarse. So for example if I export
> a function named FOO, I want to prevent people from
> defining a function FOO, but they may well define a
> type FOO.
Consider two clients of your code, both of them using your package. The
point of package locks is that there's otherwise no way of preventing
their two mutually inconsistent definitions of the type FOO from
colliding. You might want to prevent people from defining a function
FOO, but third parties should not be encouraged to believe that defining
a type FOO in your package, usually by mistake, is a good idea. In
other words, I really don't think (given that the symbol is the unit of
visibility) that the per-symbol basis is too coarse.
Cheers,
Christophe

On Oct 25, 2010, at 11:37 AM, Tobias C Rittweiler wrote:
> How do the people at ITA deal with the problem of inadvertent
> redefinition?
Almost everything is in one package, don't really worry about accidental redefinition. (although SBCL will emit a warning, at least in some cases).

> On Oct 25, 2010, at 11:37 AM, Tobias C Rittweiler wrote:
>> How do the people at ITA deal with the problem of inadvertent
>> redefinition?
>
> Almost everything is in one package, don't really worry about
> accidental redefinition. (although SBCL will emit a warning, at
> least in some cases).
except for macros the redefinition doesn't work, which can cause
*very* painful headaches: https://bugs.launchpad.net/sbcl/+bug/553943
the bug about defmacro not warning: https://bugs.launchpad.net/sbcl/+bug/434657
and although i'm not an ITA employee, our two cents on the issue is to
keep our entire codebase warning-free and keep an eye for the new
ones.
--
attila

On 25 October 2010 11:31, Attila Lendvai <attila.lendvai@...> wrote:
> and although i'm not an ITA employee, our two cents on the issue is to
> keep our entire codebase warning-free and keep an eye for the new
> ones.
>
Same here - we fail the build if any warning or even style-warning
appears, though we frob which types of warnings do or do not get
emitted.
--#f
Nobody seems more obsessed by diet than our antimaterialist, otherworldly,
New Age, spiritual types. But if the material world is merely illusion, an
honest guru should be as content with Budweiser and bratwurst as with raw
carrot juice, tofu, and seaweed slime. — Edward Abbey