[asdf-devel] a hair in :pathname specifications

[Robert Goldman]

On 6/12/10 Jun 12 -6:37 AM, Faré wrote:
> Looking at Stelian's recent patches to iolib, I saw that he uses things like:
> 
> (asdf:defsystem :iolib.syscalls
>   ...
>   :pathname #-asdf2 (merge-pathnames "syscalls/" *load-truename*)
>             #+asdf2 "syscalls/"
>   ...)
> 
> This shocked me, as I new (for having been hit badly by the issue at
> ITA and having read the code) that you can't use (merge-pathnames ...)
> like that in a component and need #. instead, since there is no EVAL
> in parse-component-form. ITA used to have lots of #.(merge-pathnames
> ...) before I implemented / parsing in our local ASDF (now merged into
> ASDF 2).
> 
> Well, it turns out that the defsystem macro itself treats :pathname
> specially and lets that argument be evaluated unlike other arguments
> and unlike :pathname for other forms. This interacts badly with some
> code I've written recently that cleans up the way we normalize
> specified pathnames for components, my code assuming we were always
> provided a valid specifier.
> 
> So the question is: what to do?
> 
> 1- Should I do nothing, thus having more uniform semantics but
> breaking compatibility with ASDF 1 and requiring users of defsystem to
> use #. in such occasions?
> 
> 2- Should I issue an ASDF 2.0 minor release that re-allows pathname
> evaluation just for defsystem forms (excluding other forms), thus
> providing better backwards compatibility?
> 
> 3- Should I issue an ASDF 2.0 minor release that does pathname
> evaluation inside parse-component-form, thus providing better
> backwards compatibility AND extending the semantics so that it be more
> uniform?

I tend to favor leaving things as they are.  I have mixed feelings about
this.  Evaluating the pathname argument makes sense, but the
un-orthogonality (suddenly this is different from all the other slots)
seems undesirable.

Best,
r