Another follow-up from yesterday's doc reviews
sionescu at cddr.org
Thu Sep 22 19:35:18 UTC 2016
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
> *behave* like CL code.
> If we can't LOAD a file with a DEFSYSTEM form, or EVAL a DEFSYSTEM
> 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
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
> its users to carefully read the source to use it properly, because
> things that are otherwise sensible cause random stupid things to
> 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
I agree it should be enforced.
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 181 bytes
Desc: This is a digitally signed message part
More information about the asdf-devel