[asdf-devel] a hair in :pathname specifications

[Faré]

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?

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
A common man marvels at uncommon things; a wise man marvels at the commonplace.
	— Confucius