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 00003b@gmail.com wrote:
On Mon, Jul 8, 2024 at 9:05 PM Scott L. Burson Scott@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.