On Mar 29, 2010, at 10:39 AM, Faré wrote: […]
So I would ask the ASDF developers to consider extending the output translation DSL to allow something like
(initialize-output-translations '(:output-translations :ignore-inherited-configuration (#p"jar:file:/**/*.jar!/**/*.*" :function SYS::ASDF-JAR-OUTPUT-TRANSLATE)))
I suggest that either you make (:function foo) a valid second value for an output-translations list, or you make said list accept a&key function argument in addition to its two current positional arguments. But having weird non-standard vararg convention for such lists is probably a bad API. The default function would be TRANSLATE-PATHNAME and the calling convention would be the same.
I'd favor the first proposal, as making :FUNCTION a real key argument would imply that the second positional parameter is optional, whereas it is actually being replaced by the (:FUNCTION ARG) parameter. When I get time to revisit the patch, I'll implement your first proposal.
I'd favor either a keyword argument or :function as a magic marker to be inserted in FIRST position, followed by a function designator (and additionally, parameters to curry?). Unless of course, you symmetrically accept a FUNCTION in first position to denote a "recognize if this matching rule applies".
I would think that we want to preserve the current ability for the user to vistually scan down the list of translations to determine what should match, so I would favor going for your second proposal. It doesn't make sense that there be a match predicate paired with a translation pathname right? So the two new possibilities for output translation lists would be:
("/**/foo/*.*" (:function FOO-OUTPUT-TRANSLATION)) ((:function BAR-PATHNAME-P) (:function BAR-OUTPUT-TRANSLATION))
--
"A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."