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 _______________________________________________ asdf-devel mailing list [email protected] http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
