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 <shafl...@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 <du...@franz.com> wrote:
>>
>> --------
>> Date: Sat, 6 Jul 2024 18:56:15 +0200
>> From: Alexander Fedorov <varedif....@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-nicknames-1
>>
>> Hopefully there are not too many conflicts with your proposed spec.
>>
>> Duane Rettig
