On 9/23/16 Sep 23 -6:24 PM, Stelian Ionescu wrote:
So, ok, what IS it about an ASD file, that is not DEFSYSTEM, that
must be evaluated inside LOAD-ASD? If it's just "you could wreck the syntax behind my back," yeah, that's true, but you could wreck the syntax behind my back and wreck the library I'm loading, too, so why is it ASDF's job to fix that here? If LOAD is broken, why is it our job to make LOAD-ASD and fix a tiny corner of the problem?
Because unless you have the resources to fix the language in a major way, you can only do small incremental improvements. Very pragmatic. Not ideal.
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.
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's obviously exaggerating, but it's a step towards taking what makes CL great, and taking that away and giving us C instead.
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?
Are we going to shove more stuff into LOAD-ASD, further divorcing the ASD-dialect from mainstream CL?
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.
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?