[asdf-devel] a hair in :pathname specifications

Faré fahree at gmail.com
Sat Jun 12 11:37:57 UTC 2010

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

[ 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

More information about the asdf-devel mailing list