fahree at gmail.com
Sat Sep 24 01:52:38 UTC 2016
On Fri, Sep 23, 2016 at 7:32 PM, Robert Goldman <rpgoldman at 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
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
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
> 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
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.
—♯ƒ • 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
More information about the asdf-devel