[asdf-devel] ASDF traverse changed behavior?

[Robert Goldman]

On 3/17/10 Mar 17 -3:31 PM, Juan Jose Garcia-Ripoll wrote:
> On Wed, Mar 17, 2010 at 3:23 PM, Robert Goldman <rpgoldman at sift.info
> <mailto:rpgoldman at sift.info>> wrote:
> 
>     E.g., it seems that we can fix one of Juanjo's two problems by simply
>     recasting one of his INPUT-FILES (?) primary method as an :AROUND
>     method.
> 
> 
> Around methods are a hack. If you later on decide to add an around
> method to ASDF then you break whatever I do. If some user decides to add
> an around method then it will break again.

For the record, I don't agree that :around methods are a hack.  Or at
any rate, no worse than (call-next-method).  If you don't like CLOS, you
won't like ASDF.  ASDF was explicitly designed to be a successor to
MK-DEFSYSTEM that exploited CLOS.

I /do/ agree that we need to layer the protocol more.  We had already
had a layer that allowed us to separate ASDF internal around methods
from ASDF user around methods.  This was removed over my protests.

It seems reasonable to me that we might want to identify an API layer
that is explicitly for people adapting ASDF to particular Lisp
implementations.  I would welcome suggestions for improving this.
>  
> 
>     As for the problem with TRAVERSE, I don't understand enough what the
>     problem is.  Can it be solved simply by adding something like:
>      (defmethod PERFORM ((op lib-op) (c cl-source-file))
>      (values))
> 
> 
> What if somebody adds another component to a system? Right now this
> means I have to track all existing ASDF components, know in advance
> which ones may form part of the module, because as it was said I am not
> allowed to write a method with a generic signature PERFORM ((op lib-op)
> (c component)) because COMPONENT is a class that ASDF defines.

The inclusion of LIB-OP should open up

(defmethod PERFORM ((op LIB-OP) (c COMPONENT)) ...)

to you.


> 
> Summing up, please you all consider this: if you forbid --in the ASDF
> specification-- to write any method that uses directly ASDF classes that
> means we are not allowed to extend ASDF systems at all.
>  * We would have to define our own system, module, component,
> operations, and these would no be allowed to coexist with ASDF systems.
>  * We would not be allowed to use the same *.asd systems that other
> library defines because those use ASDF's system classes.
>  * We would not be allowed to combine ASDF's LOAD-OP operations with our
> own components (precompiled files, etc) because we are not allowed to
> write methods using LOAD-OP and our extended classes.

I think the above is overboard.  It would be more helpful for you to
work to provide a clean description of what is an acceptable API and
what is not than to indulge in this kind of overstatement.

We cannot allow people to write arbitrary methods on arbitrary bits of
ASDF --- the whole system would become unstable and unmaintainable.  So
we MUST find a crisp way to characterize what extenders can and can't do.

Please focus your attention on helping us define a clear set of
guidelines rather than attacking the notion of limitations on the extenders.

Robert