On Mon, Feb 19, 2018 at 7:03 PM, Eric Timmons etimmons@mit.edu wrote:
Glad to help! I've also opened the following bug on SBCL to let them know about it: https://bugs.launchpad.net/sbcl/+bug/1750466.
Thanks!
Also, I checked that nothing else in ASDF uses `parse-define-package-form`, but I somehow missed until just now that it's actually exported from uiop =/. Is there any concern about another library using it? If so, I can try to fix it in such a way that the output of `parse-define-package-form` is unchanged.
I wouldn't worry about that: grepping through quicklisp systems reveals no user.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org It costs the nation millions to keep Gandhi living in poverty — Sarojini Naidu
This does seem to illustrate an issue with the current "export everything that's in UIOP" strategy.
Should we consider changing this policy?
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?
Best, r
On 19 Feb 2018, at 18:22, Faré wrote:
On Mon, Feb 19, 2018 at 7:03 PM, Eric Timmons etimmons@mit.edu wrote:
Glad to help! I've also opened the following bug on SBCL to let them know about it: https://bugs.launchpad.net/sbcl/+bug/1750466.
Thanks!
Also, I checked that nothing else in ASDF uses `parse-define-package-form`, but I somehow missed until just now that it's actually exported from uiop =/. Is there any concern about another library using it? If so, I can try to fix it in such a way that the output of `parse-define-package-form` is unchanged.
I wouldn't worry about that: grepping through quicklisp systems reveals no user.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org It costs the nation millions to keep Gandhi living in poverty — Sarojini Naidu
On Tue, Feb 20, 2018 at 3:35 PM, Robert Goldman rpgoldman@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.
-
Faré -
Robert Goldman