
<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">

<br><div><div>On 2010-04-15, at 23:30 , Juan Jose Garcia-Ripoll wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">On Thu, Apr 15, 2010 at 10:40 PM, james anderson <span dir="ltr"><<a href="mailto:james.anderson@setf.de">james.anderson@setf.de</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <br> On 2010-04-15, at 22:26 , Juan Jose Garcia-Ripoll wrote:<br> <br> > Who uses it?<br> <br> depends on what one means by "uses it"? the value in the respective<br> slot is more-or-less central to the dependency computation and is<br> initialized in the instantiation process[1]. once it plays that role,<br> is there any reason to not place the initarg in the interface?<br></blockquote></div><br clear="all">The current implementation can be done without :in-order-to, and I think Fare also has that in mind.<br></blockquote><div><br></div>yes, the initarg is not essential. however, as evident in the issues which you raise below, its presence does not contribute significantly to asdf deficiencies.</div><div><br><blockquote type="cite"><br>Personally I also find another reason to make the under-the-hoods algorithm not rely on in-order-to, and it is the following one.<br> <br></blockquote><div><br></div>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.</div><div>the :in-order-to initarg is just circumstantially involved in this. most of the initialization value is collected from the other dependency initargs.</div><div><br><blockquote type="cite">The most valuable information ASDF has is the list of dependencies which would allow one to do a topologically sorted list of components to be loaded. By loaded I do not mean compiled and loaded but just loaded, assuming everything had been already compiled.<br> <br>Currently we can not get this graph because every LOAD-OP produces a COMPILE-OP which may itself trigger a LOAD-OP of other component. LOAD-SRC-OP currently does not work to get an equivalent graph because it is not available for all components and because not all libraries take it into account in :in-order-to. ASDF also does not take it itself into account in the automated dependencies.<br></blockquote><div><br></div><div>none of which has to do with the initarg. it has to do with how the graph is annotated and the way traverse operates on it. there are lots of things one should be able to do with the dependency graph. it would be nice. your remarks suggest that you fail to appreciate how broken i believe traverse to be.[1]</div></div><div><br></div><div><blockquote type="cite"> <br>So, I would say, in order to produce that beautiful and useful list: 1) provide another mean to have a test-op (perhaps a :test-system option?), 2) remove :in-order-to, 3) implement a kind of "force-all" option to TRAVERSE which makes it behave as if nothing was loaded before and either a) fix LOAD-SRC-OP and rely on it or b) provide a means to temporarily deactivate the triggering LOAD-OP -> COMPILE-OP. With this we can use TRAVERSE to get the sorted graph.<br></blockquote><div><br></div>traverse needs to be rewritten. faré alluded to a "refactoring". with all of a .021 version bump. i'm curious, whether he manages to stop at that.</div><div><br><blockquote type="cite"> <br>Finally, note that removing :in-order-to does not mean having serial order, for we still have the other ways to express dependencies.<br></blockquote></div><div><br></div>---<div><br><div>[1] : <a href="http://github.com/lisp/de.setf.asdf.x">http://github.com/lisp/de.setf.asdf.x</a></div></div></body></html>