Hi Thanks for the writeup. Apologies for the CDR-DISCUSS mishaps.
I am one of the major polluters of the packages' namespace as I happily abuse :nicknames. I perused the specification, I like it and I agree with the comments, but I think there is an extra useful bit that is missing. I would like to be able to write *(in-package "A-VERY-LONG-AND-HAIRY-PACKAGE-NICKNAME" ; This may even be a 'global nickname'!* * :as "HAIRY-PKG" ; The 'local nickname'. )* It seems quite natural to me. Did I miss something? All the best Marco On Tue, Jul 9, 2024 at 8:19 AM Bart Botta <000...@gmail.com> wrote: > On Mon, Jul 8, 2024 at 9:05 PM Scott L. Burson <sc...@sympoiesis.com> > wrote: > > > 2.2: The strongest point I want to make here is that a correctable error > should be signalled whenever a package becomes fully shadowed by another > package (all of its global names are shadowed), with a restart that > requests a new local nickname for the shadowed package in the shadowing > package(s). We want to alert the user to the situation, and strongly > encourage them to add a new nickname (global or local) in the relevant > source file so as to make the fully shadowed package accessible again. > Meanwhile, we supply the restart to make it easy to remove the shadowing in > the current session. > > I think signalling an error at the point where a package becomes > completely shadowed is a bad idea . It destroys the locality of the > local nicknames and brings us back to the problem where you can't load > two systems at the same time because they happened to both want to use > the same convenient name. Arguably one of them has a bad name, and > should have other names, but lots of CL code is old and un- or > under-maintained, and we shouldn't be annoying users about them just > for a very rare edge case. > > > In my view, the purpose of local nicknames is to shorten frequently > typed package prefixes. Using them for anything else seems potentially > unsafe. > > Another intended use case was people who want to substitute one > package for another without having to change the code (either picking > from multiple implementations depending on requirements, or replacing > an old lib with a compatibility layer, etc). I've seen people describe > doing that with :USE, and package local nicknames should support it as > well, and more safely in cases where any of those packages might > change over time. > -- Marco Antoniotti, Professor tel. +39 - 02 64 48 79 01 DISCo, University of Milan-Bicocca U14 2043 http://dcb.disco.unimib.it Viale Sarca 336 I-20126 Milan (MI) ITALY
