On Fri, Apr 16, 2010 at 12:01 AM, james anderson <james.anderson@setf.de> wrote:
you will need to elaborate on why this matters. the primary dependencies are all in a list which is bound to the in-order-to slot.
the :in-order-to initarg is just circumstantially involved in this. most of the initialization value is collected from the other dependency initargs.

Yes, but everything is transformed into an in-order to internally when parsing the system definition. The result is a duplicated list of dependencies :in-order-to load-op and :in-order-to compile-op.

The additional problem is that right now we have a dichotomy between load and load-src-op and apart from the cases in which :in-order-to is used for testing, the other cases just write dependencies for one of the operations and not for the other.

The third problem is that the in-order to mechanism does not provide any kind of inheritance and if I tried to write a fix for load-src-op that creates the hierarchy

operation
+- compile-op
+- load-op
    +- compile-and-load-op
    +- load-source-op

this does not work.

your remarks suggest that you fail to appreciate how broken i believe traverse to be.[1]

Your remarks fail to appreciate how good and useful I believe a properly written traverse could be.

Juanjo

--
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://tream.dreamhosters.com