On Fri, Sep 23, 2016 at 7:32 PM, Robert Goldman <rpgoldman@sift.net> wrote:
But my claim is that it is NOT an improvement if you turn a language which is incrementally compilable into a language that only works if you load it through LOAD-ASD.
It works perfectly in slime, if you enable swank-asdf.
What we have done with LOAD-ASD is to take away code that is runnable with compile-sexp and replace it with code that is only runnable with LOAD-ASD.
It was never more "runnable" than it is. Never. ASDF 1 created a temporary package around loading a .asd file, and changed *package* to that. ASDF 3 bailed on that and introduced ASDF-USER, there again binding *package* to that. There was no regression at any point. Actually, because the package used to be destroyed, ASDF 1 was quite a pain to trace or debug code written without in-package, whereas ASDF 3 makes it easier. Users have always been able to write a .asd file without having to write in-package, and writing in-package would NOT protect you against someone loading a system while under a package that re-bound in-package (e.g. some CL-in-CL implementation). If you fail to bind proper syntax around load .asd's, then you prevent people from using load-system from within the middle of their arbitrary session where they changed the syntax. Worse, you prevent them from ever using any function that indirectly does, which means they have to worry about the implementation details of all their transitive dependencies, which is absurd and contrary to the need-to-know principle. Once again, swank-asdf also knows how to load a .asd file with load-asd. It might not be good at identifying the package as asdf-user, but then that's a bug in slime that can be fixed in slime.
It's obviously exaggerating, but it's a step towards taking what makes CL great, and taking that away and giving us C instead.
I beg to differ. You want to force people who write .asd files to be super defensive and use in-package, for fewer actual warranties, with a major compatibility break, for no tangible benefit whatsoever to anyone.
Now, of course, people like me can put our packages in our asd files and things should keep working, but what's the contract with the programmer here?
There was a clear contract: the .asd writer doesn't have to care about the context of the user (that he doesn't control), and the asdf user doesn't have to care about the context of the .asd file (that gets automatically setup for him). You're breaking this contract, and
Are we going to shove more stuff into LOAD-ASD, further divorcing the ASD-dialect from mainstream CL?
It's not divorcing the asd dialect from CL. It's setting up the syntactic context so to isolate the .asd writer from the .asd user, as is the proper thing to do.
Anyway, here's my proposed solution:
1. Don't enforce the use of LOAD-ASD. Probably people can understand this well enough.
2. Do enforce the use of MAKE-OPERATION. I doubt that this will interfere with people that badly (particularly because most people won't be doing it), and if it does, it's not that hard to replace a MAKE-INSTANCE with a MAKE-OPERATION. Also, allowing people to willy-nilly create instances of a class whose instances are supposed to be interned (i.e., EQ-comparable) is a Bad Thing.
To be clear, I'm all in favor of enforcing the use of MAKE-OPERATION. I'm just somewhat opposed about doing without providing heads up to users. If you're not willing to hunt users in Quicklisp (for which Anton V's cl-test-grid can help), then it's better to give them heads up to find out. e.g. document things loadly in the manual (that still talks about make-instance), announce with the next release, and enforce the following release.
If CL-TEST-GRID or some other testing shows that this causes Quicklisp to melt-down, then we can consider replacing my continuable error call with a WARNING.
ACCEPTABLE-P?
Yes. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Dost thou love life? Then do not squander time, for that's the stuff life is made of. — Benjamin Franklin