On Fri, 2016-09-23 at 18:32 -0500, Robert Goldman wrote: > 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.
Enforce it but add a way to disable it, but not a simple dynamic variable. A new function, e.g. (setf (asdf:flag :enforce-load-asd) nil) And a way for the programmer to query the current set of ASDF flags. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur.
signature.asc
Description: This is a digitally signed message part
