Thanks for your reply!
About MAKE-PACKAGE - good catch, will fix that! This is definitely not what I have intended, nor what is currently implemented by any other implementation. I have blindly copied it from DEFPACKAGE, not noticing that it delegates errors to MAKE-PACKAGE as well.
About DEFPACKAGE - this is analogous to the :USE clause. Note that the "incompletely-created named package" problem indeed exists in the ANSI standard, since when the :SHADOW clause is present, it must call MAKE-PACKAGE with an empty :USE list. After that it calls SHADOW, and finally calls USE-PACKAGE. If a name conflict happens at the last stage, a correctable error is signaled; and if you don't resolve those conflicts but instead exit the debugger via the ABORT restart, you will end up with a defined named package with an empty USE-LIST.
Best regards, Alexander Fedorov.
On Sun, 7 Jul 2024 at 05:34, Steve Haflich shaflich@gmail.com wrote:
There is a very subtle semantic problem in this proposal. Focus on this seemingly-harmless requirement on the :local-nicknames arg to {def, make-}package:, so subtle that probably no one else has noticed it yet
Name conflict errors are handled by the underlying calls to add-package-local-nickname.
where apln is specified to signal a package error under certain circumstances. It is in the design of ANSI CL -- though rarely exploited in practice -- that normal errors can be handled and recovered predictably and harmlessly. There are many circumstances in CL where an error might be signaled by a standard function, but all the ones I can think of (e.g. vector-push or open of a file) would be expected to leave the world in an unaltered state (in any way that can be detected within the ANS) when an error is signaled. (I'm discounting bumps to *gensym-counter* when a compilation fails.) But this "handled by" specification strongly implies implementation and the order of function side effects; apln cannot be called until after the package exists, but when t, so subtle that probably no one else has noticed it yethe error is signaled and the defpackage "fails" is the incompletely-created named package left around?
Quite possibly this problem already exists somewhere within the ANS package system -- haven't thought about it very hard -- but it isn't the sort of thing conformance test suites would test for.
On Sat, Jul 6, 2024 at 1:04 PM Duane Rettig duane@franz.com wrote:
Date: Sat, 6 Jul 2024 18:56:15 +0200 From: Alexander Fedorov <varedif.a.s@gmail.com> 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.
Alexander,
I have not read this specification draft, but when asked for plns by a customer I found it easy to implement years ago with little controversy from my point of view, even on top of our Hierarchichal Packages implementation. The only discrepancy I had found (which might now be corrected, since it was in 2019) was that sbcl's documentation described plns as not being abot to co-exist with global names. I made the assumption that the documentation was either incorrect or out-of-date, based on my experiments with plns in sbcl as I was implementing them in Allegro CL.
The documentation for Allegro CL has been available since the implementation was provided in a patch for 10.1, and the current description is here:
https://franz.com/support/documentation/current/packages.html#local-nickname...
Hopefully there are not too many conflicts with your proposed spec.
Duane Rettig