The comments in the file say that we *must* use load-asdf to load a .asd file, but not *WHY* we must do so.
Why is this necessary?
E.g., I have a makefile that lets me build a number of executables using my choice of lisp.
Each time, to build the executable, it starts a lisp, loads the ASDF file (using --load or equivalent), and then uses asdf:make.
I could use --eval (asdf:load-asdf "myfile.asd") but why is it mandated?
The comments in the file say that we *must* use load-asdf to load a .asd file, but not *WHY* we must do so.
Why is this necessary?
Because asdf:load-asdf sets up the correct evaluation environment, including setting the correct *package*.
On 9/22/16 Sep 22 -1:56 PM, Stelian Ionescu wrote:
The comments in the file say that we *must* use load-asdf to load a .asd file, but not *WHY* we must do so.
Why is this necessary?
Because asdf:load-asdf sets up the correct evaluation environment, including setting the correct *package*.
OK, again, if this is required, why don't we ENFORCE it?
It would be trivial to bind a special variable around the body of LOAD-ASD, and put something in DEFSYSTEM that will raise an INTELLIGIBLE error if that variable is not so bound
(error "Do not load an ASDF system definition outside of ASDF:LOAD-ASD")
Otherwise, we are just encouraging programmers to shoot themselves in the foot.
I will put in place such a check.
On Thu, 2016-09-22 at 14:04 -0500, Robert Goldman wrote:
On 9/22/16 Sep 22 -1:56 PM, Stelian Ionescu wrote:
The comments in the file say that we *must* use load-asdf to load a .asd file, but not *WHY* we must do so.
Why is this necessary?
Because asdf:load-asdf sets up the correct evaluation environment, including setting the correct *package*.
OK, again, if this is required, why don't we ENFORCE it?
Because in some specific cases it could be made to work without it (all ASDF symbols package-prefixed, etc...) and some old-timers complained that we're breaking their dev workflow if we make it impossible to reload an .asd using C-c C-c or cl:load
On 9/22/16 Sep 22 -2:07 PM, Stelian Ionescu wrote:
On Thu, 2016-09-22 at 14:04 -0500, Robert Goldman wrote:
On 9/22/16 Sep 22 -1:56 PM, Stelian Ionescu wrote:
The comments in the file say that we *must* use load-asdf to load a .asd file, but not *WHY* we must do so.
Why is this necessary?
Because asdf:load-asdf sets up the correct evaluation environment, including setting the correct *package*.
OK, again, if this is required, why don't we ENFORCE it?
Because in some specific cases it could be made to work without it (all ASDF symbols package-prefixed, etc...) and some old-timers complained that we're breaking their dev workflow if we make it impossible to reload an .asd using C-c C-c or cl:load
I'm one of those old-timers, TBQH. I interactively compile a lot of code, and I don't see why DEFSYSTEM forms should be different.
I'm not a big fan of making stuff that looks like CL code, but doesn't *behave* like CL code.
If we can't LOAD a file with a DEFSYSTEM form, or EVAL a DEFSYSTEM form, why do we READ them? Why don't we make DEFSYSTEM forms NOT be legal CL forms?
I don't want ASDF to turn into a minefield of assumptions that require its users to carefully read the source to use it properly, because things that are otherwise sensible cause random stupid things to happen.
So: let's either ENFORCE the use of LOAD-ASD or let's get rid of it. Not enforcing it if it needs enforcing is the bad midpoint on this continuum.
On Thu, 2016-09-22 at 14:24 -0500, Robert Goldman wrote:
On 9/22/16 Sep 22 -2:07 PM, Stelian Ionescu wrote:
On Thu, 2016-09-22 at 14:04 -0500, Robert Goldman wrote:
On 9/22/16 Sep 22 -1:56 PM, Stelian Ionescu wrote:
The comments in the file say that we *must* use load-asdf to load a .asd file, but not *WHY* we must do so.
Why is this necessary?
Because asdf:load-asdf sets up the correct evaluation environment, including setting the correct *package*.
OK, again, if this is required, why don't we ENFORCE it?
Because in some specific cases it could be made to work without it (all ASDF symbols package-prefixed, etc...) and some old-timers complained that we're breaking their dev workflow if we make it impossible to reload an .asd using C-c C-c or cl:load
I'm one of those old-timers, TBQH. I interactively compile a lot of code, and I don't see why DEFSYSTEM forms should be different.
I'm not a big fan of making stuff that looks like CL code, but doesn't *behave* like CL code.
If we can't LOAD a file with a DEFSYSTEM form, or EVAL a DEFSYSTEM form, why do we READ them?
Parsing DEFSYSTEM forms with CL:READ is simply convenient, especially since, as Lispers, we expact Lisp syntax.
Why don't we make DEFSYSTEM forms NOT be legal CL forms?
They are CL forms, they just require a certain implicit evaluation environment, which is set up by ASDF:LOAD-ASD.
I don't want ASDF to turn into a minefield of assumptions that require its users to carefully read the source to use it properly, because things that are otherwise sensible cause random stupid things to happen.
So: let's either ENFORCE the use of LOAD-ASD or let's get rid of it. Not enforcing it if it needs enforcing is the bad midpoint on this continuum.
I agree it should be enforced.
On Thu, Sep 22, 2016 at 3:04 PM, Robert Goldman rpgoldman@sift.net wrote:
It would be trivial to bind a special variable around the body of LOAD-ASD, and put something in DEFSYSTEM that will raise an INTELLIGIBLE error if that variable is not so bound
(error "Do not load an ASDF system definition outside of ASDF:LOAD-ASD")
As I understand it, the issue isn't really with the DEFSYSTEM form itself. Instead, the issue is with all the *other* code that could be in the .asd file as the manual states that symbols from CL, ASDF, and UIOP will all be available inside an .asd file without an IN-PACKAGE form.
EVAL'ing a DEFSYSTEM form seems like a totally reasonable thing to do outside the context that LOAD-ASD sets up. And actually, ASDF itself does EVAL DEFSYSTEM forms, in package-inferred-system.lisp at the very least.
-Eric
On Thu, Sep 22, 2016 at 4:18 PM, Eric Timmons etimmons@mit.edu wrote:
As I understand it, the issue isn't really with the DEFSYSTEM form itself. Instead, the issue is with all the *other* code that could be in the .asd file as the manual states that symbols from CL, ASDF, and UIOP will all be available inside an .asd file without an IN-PACKAGE form.
Oh, and also about making sure DEFSYSTEM itself doesn't need to be prefixed with a package.
As I said, this is where the DWIM slipped in....
I never minded keeping track of packages, and in retrospect I claim that getting the package right imposes less complexity than trying to keep track of all the stuff ASDF does behind your back to keep you from having to type "ASDF:"
Sent from my iPhone
On Sep 22, 2016, at 15:23, Eric Timmons etimmons@mit.edu wrote:
On Thu, Sep 22, 2016 at 4:18 PM, Eric Timmons etimmons@mit.edu wrote: As I understand it, the issue isn't really with the DEFSYSTEM form itself. Instead, the issue is with all the *other* code that could be in the .asd file as the manual states that symbols from CL, ASDF, and UIOP will all be available inside an .asd file without an IN-PACKAGE form.
Oh, and also about making sure DEFSYSTEM itself doesn't need to be prefixed with a package.
Actually now LOAD-ASD controls syntax, sets the readtable, controls the pretty-printer, sets up a cache, and a handler. And who knows what it will do tomorrow?
For the record, I'm not a fan. I would prefer that asd files were normal lisp. But they aren't, so I don't think we should lie about it, and I don't want to field alleged bug reports that arise because someone thought they were, when they are not.
I understand Stelian's point, but I still regret our making DEFSYSTEM look like normal code when it no longer is. In retrospect, I think we jumped the shark way back in the day when we gave up making programmers choose their own packages for the asd files. Making a package, and then instituting ASDF-USER was the top of the slippery slope.
But we're down the slope now, so I propose to at least warn programmers when they're doing something we have defined as wrong.
We could make this a continuable error as a concession to people who know that they want to evaluate these forms outside LOAD-ASD, but that's as far as I'm prepared to go.
Sent from my iPhone
On Sep 22, 2016, at 15:18, Eric Timmons etimmons@mit.edu wrote:
On Thu, Sep 22, 2016 at 3:04 PM, Robert Goldman rpgoldman@sift.net wrote: It would be trivial to bind a special variable around the body of LOAD-ASD, and put something in DEFSYSTEM that will raise an INTELLIGIBLE error if that variable is not so bound
(error "Do not load an ASDF system definition outside of ASDF:LOAD-ASD")
As I understand it, the issue isn't really with the DEFSYSTEM form itself. Instead, the issue is with all the *other* code that could be in the .asd file as the manual states that symbols from CL, ASDF, and UIOP will all be available inside an .asd file without an IN-PACKAGE form.
EVAL'ing a DEFSYSTEM form seems like a totally reasonable thing to do outside the context that LOAD-ASD sets up. And actually, ASDF itself does EVAL DEFSYSTEM forms, in package-inferred-system.lisp at the very least.
-Eric
On Thu, Sep 22, 2016 at 4:44 PM, Robert P. Goldman rpgoldman@sift.net wrote:
Actually now LOAD-ASD controls syntax, sets the readtable, controls the pretty-printer, sets up a cache, and a handler. And who knows what it will do tomorrow?
Oooph, didn't realize that was in there as well. At least those effects aren't advertised in the manual (I think)?
For the record, I'm not a fan. I would prefer that asd files were normal lisp. But they aren't, so I don't think we should lie about it, and I don't want to field alleged bug reports that arise because someone thought they were, when they are not.
Honestly, I'd go the other way and say I wish ASD files were not LOAD'able. It'd make it easier to analyze a system without the possibility of incurring side effects due to whatever code the developer decided to put in there (this has made my life annoying a couple of times). But that's probably not worth thinking about until ASDF 4 rolls around.
We could make this a continuable error as a concession to people who know that they want to evaluate these forms outside LOAD-ASD, but that's as far as I'm prepared to go.
That's probably a good compromise.
-Eric
.asd files are Lisp code, but this Lisp code must be loaded in the correct context. Just like a random Lisp file won't even load if its packages haven't been defined, or the readtable is wrong, etc., a random .asd file won't run if it's not loaded in the correct context.
This is NOT new: ASDF 1 (and ASDF 2 after it) even used to create a new package around the loading of each and every .asd file -- and delete it afterwards! And there wasn't even an exported function that users could call to achieve the same effect, until 2.011.3 (Dec 2010).
Now if you use swank-asdf, I made sure that it calls load-asd when you use C-c C-k on a .asd file. I also implemented other goodies, so that compiling a file would be done with perform compile-op, but the slime maintainers disabled them by default. Sigh.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org I’d like to confess, Papa, at that moment I discovered that I really like killing. — Ernesto "Che" Guevara
On Thu, Sep 22, 2016 at 5:19 PM, Eric Timmons etimmons@mit.edu wrote:
On Thu, Sep 22, 2016 at 4:44 PM, Robert P. Goldman rpgoldman@sift.net wrote:
Actually now LOAD-ASD controls syntax, sets the readtable, controls the pretty-printer, sets up a cache, and a handler. And who knows what it will do tomorrow?
Oooph, didn't realize that was in there as well. At least those effects aren't advertised in the manual (I think)?
For the record, I'm not a fan. I would prefer that asd files were normal lisp. But they aren't, so I don't think we should lie about it, and I don't want to field alleged bug reports that arise because someone thought they were, when they are not.
Honestly, I'd go the other way and say I wish ASD files were not LOAD'able. It'd make it easier to analyze a system without the possibility of incurring side effects due to whatever code the developer decided to put in there (this has made my life annoying a couple of times). But that's probably not worth thinking about until ASDF 4 rolls around.
We could make this a continuable error as a concession to people who know that they want to evaluate these forms outside LOAD-ASD, but that's as far as I'm prepared to go.
That's probably a good compromise.
-Eric
-
Eric Timmons -
Faré -
Robert Goldman -
Robert P. Goldman
-
Stelian Ionescu