Thank you very much for the clarifications. I will fix up the documentation accordingly.
Best, R Sent from my iPad On Jul 31, 2013, at 17:44, Faré <fah...@gmail.com> wrote: > On Wed, Jul 31, 2013 at 3:45 PM, Robert Goldman <rpgold...@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. >
