On Wed, Jul 27, 2016 at 6:28 PM, Robert Goldman rpgoldman@sift.net wrote:
Once upon a time in old ASDF, there was an idea that one might put slots on operations. IIRC, this worked oddly, at best, because it wasn't clear how to propagate these slot values around in the plans that ASDF built.
OTOH, we could really use the ability to add information to some of the ASDF operations. For example, now that we have an IMAGE-OP, we really don't want the images hidden away in the .cache directory where they are hard to find.
Justification: it's fine to have fasl files hidden away there, because the fasls are loaded by ASDF:LOAD-OP based on computed fasl file locations. But if you want to load an image, you need to find that image *before* you have ASDF -- even before you have lisp -- so an invisible file, whose location is computed, is really inappropriate.
Note also that by Faré's design principle -- the one who knows should specify -- this information cannot be somehow programmed into the system -- it must be supplied by the user.
I'm inclined to think we could allow the user to set an output-file for some of the bundle operations with a keyword argument to OPERATE, and then jam the value of the keyword argument into the bundle-op for it to be written.
This works, I think, because it's a trivial case. If we try to put some properties on an operation and need them to be propagated around the plan, I think we just lose.
Comments?
I generally agree with your concerns and solutions. A few thoughts:
* ASDF 3 kept from ASDF 1, for backward compatibility, the idea that the arguments to OPERATE are passed as initarg to OPERATION. This is completely backward. ASDF 1 was trying to conflate into the OPERATION object many concerns, most of which ASDF 3 has moved to the new PLAN object. The ASDF action traversal model actually depends on any slots of OPERATION being *not meaningful*, only cosmetic at best, or global constants that will never change, etc. That was true implicitly in ASDF 1 and ASDF 3 made it somewhat more explicit. Because they don't really work, about no one relies on operation slots anyway, except that SLIME uses operation-forced for some obscure hack, despite my repeated attempts to get them to stop (I never had a good rapport with SLIME maintainers, except for João Távora who eventually left to fork SLY). The operation slots were also preserved to maintain backward compatibility with the old ECL bundle operations -- but a different interface was provided (moving the slots to components instead, where they belong), so hopefully anyone who still uses the old interface can be told to just use the new one.
* If we altogether remove this non-working operation initargs thing, then we free the keyword args of OPERATE (and its front-ends load-system, etc.) for more useful things. Among them, a :output-file and/or :output-files keyword could populate an asdf-cache entry for the output-files of the requested action (pair of operation and component) and select the output location.
* Since ASDF3, bundle operations currently magically use :build-pathname if the requested operation is the :build-operation (though even that is broken in some versions of ASDF3). If you provide a better mechanism, this one should probably go away, since it fails proper division of labor, indeed, and I don't think anyone relies on it but a few of my own systems, that I will happily update.
So, once again, we are being held up by some unfortunate choices of ASDF 1, and there's a transition ahead. My recommendation would be to get SLIME to stop using operation-forced, make sure the ECL folks are not using the old interface (unlikely since we renamed the bundle operations recently; at least if they could update their code for that, they presumably can update their code to put linker information in components, not operations). Then, include these backward-incompatible changes in a 3.2 branch.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org If there's a book you really want to read but it hasn't been written yet, then you must write it. — Toni Morrison [same with software, —♯f]