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
>

Reply via email to