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
On Sat, 2010-06-12 at 07:37 -0400, 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 would leave things as they are. The upgrade to ASDF2 is trivial so I see no point in trying to be backwards-compatibile here
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
On 12 June 2010 13:45, Robert Goldman rpgoldman@sift.info wrote:
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.
OK, before I throw it away, here's the patch I won't commit that implemented the backwards compatibility option 2 from my previous email.
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Life is a sexually transmitted disease with 100% mortality.
-
Faré -
Robert Goldman -
Stelian Ionescu