Issues with package location information on SBCL

[Faré]

On Tue, Feb 20, 2018 at 3:35 PM, Robert Goldman <rpgoldman at sift.info> wrote:
> This does seem to illustrate an issue with the current "export everything
> that's in UIOP" strategy.
>
> Should we consider changing this policy?
>
1- UIOP reexports everything that individual subpackages of UIOP
export. I believe that's a simple and good policy. If a helper must
remain private, don't export it in the subpackage.
2- UIOP/PACKAGE is special, in that it is defined by defpackage (for
bootstrap reasons), and that therefore to portably ensure
upgradability, the list of symbols it exports MAY NEVER CHANGE, EVER.
No adds, no deletes, no renames. No change. If you need any change,
define and export a different package. Or use defpackage to define an
empty package or constant package, then define-package to import-from
and reexport from it.

> Or, if we have "internal" functions that we don't want to be visible through
> UIOP/DRIVER, should we simply not export them from the sub-packages and use
> :import-from to move them among the sub-packages?
>
Yes, that's the idea so far.

Also, we've moved symbols within UIOP in the past, and the
UIOP/subpackage names aren't stable. If you're using a utility in
UIOP, use UIOP: as a symbol prefix, don't use the symbol from its
current subpackage.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Statism is the secular version of salvation through faith: it doesn't
matter what bureaucrats do, only that they do it with good intentions.