Another follow-up from yesterday's doc reviews

[Robert P. Goldman]

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 at mit.edu> wrote:
> 
>> On Thu, Sep 22, 2016 at 3:04 PM, Robert Goldman <rpgoldman at 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
>