[asdf-devel] ASDF 3.0.2.1 released

[Faré]

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.