My opinions on the issues: 2.1: I very weakly prefer 2.1.7, NICKNAMED-PACKAGE-IF-SUCCESSFUL. If we're going to return anything other than T, we might as well return the value that carries the most information. But I doubt anyone will ever care, though I agree that it should be standardized.
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. If we do that, then I think it won't matter too much how the printer deals with a fully-shadowed package, as it won't have to do so very often. I would go with 2.2.7 (proposal PRINT-UNREADABLY). I can't see introducing an obscure and cryptic syntax, that users probably won't recognize, for such a rare case; better to make it completely clear what is going on. 2.3: I strongly support Martin Simmons's new proposal. In my view, the purpose of local nicknames is to shorten frequently typed package prefixes. Using them for anything else seems potentially unsafe. The catch, of course, is that implementing this behavior is likely to break existing code, though OTOH the fix is not difficult. 2.4: I strongly support 2.4.4, NO-EFFECT. 2.5: I would simply disallow it, with an uncorrectable error. What are we trying to do here, win the Obfuscated Lisp Contest? 2.6: I agree with 2.6.3, EXTRA-KEYWORD-ARGUMENT-LIST. 2.7: package-locally-nicknamed-by-list doesn't seem felicitously defined to me in the first place. Shouldn't it return an alist of package and local nickname? Other than that, I have no opinion. 2.8: I agree with 2.8.4, NOT-AFFECTED-BY-LOCAL-NICKNAMES. 2.9: I don't think it should be allowed to use the empty string as the name or nickname of any package other than the keyword package. (See above crack about the Obfuscated Lisp Contest.) -- Scott On Sat, Jul 6, 2024 at 9:58 AM Alexander Fedorov <varedif....@gmail.com> wrote: > Dear all, > > Over 10 years ago, SBCL implemented the Package-Local Nicknames (PLNs) > extension. Since then, PLNs have also been adopted by multiple > implementations (ABCL, CCL, ECL, Clasp, Allegro CL and LispWorks) and > are now widely used in many projects. > > However, PLNs are still considered experimental, as stated in the SBCL > manual, since there is no formal specification for them, and each > implementation interprets various corner cases differently. While the > need for a specification has been previously discussed, I was unable > to find any publicly accessible draft for one. > > Therefore, I have drafted a specification intended to become a CDR > document. I initially wrote this draft about a year ago and have > recently revised it. You can find the latest version here: > https://gleefre.github.io/cdr-package-local-nicknames/index.html. > > There are currently nine unresolved standardization issues, each with > at least one proposed resolution. Input on those issues would be > particularly helpful, but any feedback is welcome! > > P.S. I am sharing this link across multiple platforms to reach as many > lispers as possible. This includes various mailing lists (Lisp Pro, > CDR-discuss and -devel for various CL implementations); IRC channels > (#commonlisp and implementation-specific ones); the Lisp Discord > server; several Telegram groups; and a post on Reddit. If you have any > suggestions for additional places to share the link, please let me > know. > > My apologies to those receiving this message multiple times. > > Best regards, > Alexander Fedorov. >
