As I am writing a parting article (for ELS 2014? ILC 2014?) on the what and wherefore of ASDF3, I tackled the question of force and force-not, and was reminded about that discussion whether I got it right or backward when I gave force precedence over force-not. https://bugs.launchpad.net/asdf/+bug/1184002
Then I retold how force-not was implemented at the request of Erik Pearson, who wanted to be able to declare some systems as "builtin" and not to be reloaded; their code not expensively scanner for upgrades (or worse, for downgrades). Then it came to me: duh, of course force-not should take precedence over force. The use case is clear and clearly legitimate: extending the "base" system such that you can extend it, but not redefine the locked package; yet being able to force some or all of the rest of the system.
I don't see a clear cut case in the the opposite side. Maybe one of you can tell.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The weak terrorist who predictably loses, causing death for those he claims to defend is infinitely more evil than the strong one who wins.
This has always been my impression, as well: force-not serves to block force, so should have precedence. I am pretty sure there is a launchpad ticket discussing this. I would be happy to get a patch in to that effect before our long-awaited release.
P.S. I have substantially expanded the number of nodes in the manual, improving the cross-referencing. Had a crisis at work, so couldn't quite finish this (I would like to do one more end-to-end edit), but then consider us good to go.
Sent from my iPad
On Mar 4, 2014, at 1:18, Faré fahree@gmail.com wrote:
As I am writing a parting article (for ELS 2014? ILC 2014?) on the what and wherefore of ASDF3, I tackled the question of force and force-not, and was reminded about that discussion whether I got it right or backward when I gave force precedence over force-not. https://bugs.launchpad.net/asdf/+bug/1184002
Then I retold how force-not was implemented at the request of Erik Pearson, who wanted to be able to declare some systems as "builtin" and not to be reloaded; their code not expensively scanner for upgrades (or worse, for downgrades). Then it came to me: duh, of course force-not should take precedence over force. The use case is clear and clearly legitimate: extending the "base" system such that you can extend it, but not redefine the locked package; yet being able to force some or all of the rest of the system.
I don't see a clear cut case in the the opposite side. Maybe one of you can tell.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The weak terrorist who predictably loses, causing death for those he claims to defend is infinitely more evil than the strong one who wins.
On Tue, Mar 4, 2014 at 8:06 AM, Robert P. Goldman rpgoldman@sift.info wrote:
This has always been my impression, as well: force-not serves to block force, so should have precedence. I am pretty sure there is a launchpad ticket discussing this. I would be happy to get a patch in to that effect before our long-awaited release.
P.S. I have substantially expanded the number of nodes in the manual, improving the cross-referencing. Had a crisis at work, so couldn't quite finish this (I would like to do one more end-to-end edit), but then consider us good to go.
Well, you saw it clearer than I did, then. My apologies for not getting whatever explanations you gave.
Also, if I understand Erik Pearson's use-case, there might usefully be a special variable that gets to be the default value of :force-not, say, *frozen-systems*, something.
I leave that to you.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org A mathematician is a machine for converting coffee into theorems. [A co-mathematician is a machine for converting cotheorems into fee.]
-
Faré -
Robert P. Goldman