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.