On Wed, Jul 31, 2013 at 3:45 PM, Robert Goldman rpgoldman@sift.info wrote:
Will do. I didn't get around to documenting RECYCLE per our conversation on the ticket. I have pushed a revision (3.0.2.2) with documentation, perhaps you could review? In particular, I don't adequately understand the :MIX option, so have left it without documentation.
(:MIX PKG1 PKG2 ... PKGn) takes a list of package designators, and (a) behaves like (:USE PKG1 PKG2 ... PKGn) (b) uses (:shadowing-import-from ...) to resolve conflicts in favor of the first found symbol. (c) may still error out if there is a conflict with an explicitly :shadowing-import-from symbol.
Would it be reasonable to have DEFINE-PACKAGE have keyword arguments as well as the &rest parameter? The idea would be to make the information an emacs (or other) environment displays to the programmer be more useful.
DEFINE-PACKAGE does *not* take keyword arguments. It takes a &REST argument that is an alist of clauses, similar to DEFPACKAGE. Your docstring is therefore incorrect.
Also, REEXPORT is subtle in that it exports symbols with the same name as those from the reexported packages, but they need not be the same as those imported from the package, for they may have been shadowed (and the packages may not even be imported?). Maybe a suboptimal name (with usual compatibility issues if you rename).
Another related question: in ENSURE-PACKAGE, there's a case where we ignore names that the programmer has asked us to UNINTERN (when they are :INHERITED). Question: should we be signaling this with a WARNING, in case the user's expressed intent is being violated? Or is this something that must be violated sometimes in order to effectively upgrade (in which case we should leave this here).
My memories are dim, but IIRC, inherited symbols are not considered "interned", unless they are imported (which also happens implicitly when they are exported).
- Maybe refactor duplicate-names so it doesn't inherit from
system-definition-error ? Or have a function of the same name be called that is defined later to throw the error?
That seems possible, or perhaps we should just have an ASDF/CONDITIONS package and kick *all* of the conditions up the dependency order? If you want one, just import it or use this package. That seems possibly to cause upgrade issues, though, so I have left this undone.
I would try to keep the conditions next to code that uses them, introducing each one as late as possible. But that's just me.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org ...so this guy walks into a bar. "The usual, Mr. Descartes?" the barman asked. "I think not," Rene replied, and promptly disappeared.