[armedbear-devel] [asdf-devel] Patches for ABCL against asdf-1.641
evenson at panix.com
Mon Mar 29 09:33:22 UTC 2010
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
>>>> '(:output-translations :ignore-inherited-configuration
>>>> (#p"jar:file:/**/*.jar!/**/*.*" :function
>>> 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."
More information about the armedbear-devel