[asdf-devel] ASDF 3.0.2.1 released

[Robert P. Goldman]

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é <fahree at gmail.com> wrote:

> On Wed, Jul 31, 2013 at 3:45 PM, Robert Goldman <rpgoldman at 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.
>