Enforcing assumptions

[Faré]

On Sep 23, 2016 12:25 PM, "Robert Goldman" <rpgoldman at sift.net> wrote:
>
> On 9/23/16 Sep 23 -9:52 AM, Faré wrote:
> > 1- The requirement to always use make-operation currently only applies
> > to code within ASDF itself and well-behaved extensions. Before you
> > enforce it more widely, you have to make sure no one in Quicklisp does
> > it. You could have shared initialize check that: a) no instance of that
> > class with given initargs exists yet in *operations* and hopefully b)
> > there initargs are always null (goodbye, make-build!)
>
> Your docs clearly say that these MUST be built this way.  If you want to
> say "must" then I will enforce "must."  If you want "may," we can have
> "may" as in "For more efficient functioning, please use MAKE-OPERATION
> to create all operation instances."
>
Well, at this moment it's only a performance optimization. The goal of
enforcing the invariant would be to eventually support operations with
meaningful initargs. So the question is: where are you going and/or what
options do you want to leave open? Enabling initargs? Forbidding them?
Either way, make-operation can help you enforce the invariant. And either
way requires more work. But using make-operation makes the code more
future-proof.

> Please articulate why you say "All operation instances MUST be created
> through this function"?  I like the idea of having a clean API, but I
> also note that there is code that effectively interns the results of
> MAKE-OPERATION. What is the design rationale for this?  Do you wish to
> be able to EQ-compare them?  If not, why do you intern these objects in
> the *OPERATIONS* table?  Is it really so expensive to create an
> OPERATION that we need to memoize?  Or is it because we simply create so
> many, and this improves GC behavior?
>
Better GC is nice, but yes, having tables indexed by a pair of operation
and component would be much better than having hacks like node-for... and
it requires everyone using make-operation.

> WRT Quicklisp:  I do NOT accept that I have to check all of Quicklisp
> for ANYTHING. I am willing to be INFORMED by results of such checks, but
> I do NOT have time to make such checks.
>
> I don't expect other people to test my SIFT code, and I don't have time
> to check arbitrary CL libraries, much less arbitrary CL libraries on
> arbitrary implementations and operating systems.
>
> So, no.  If someone else wants to test other things.
>
You surprise me. Historically, you've always been a strong voice for
backward compatibility and being extra cautious about not breaking other
people's code, especially not so without extra warnings and heads up, even
more so if we're reversing something the manual used to advertise.

I wouldn't consult Quicklisp when implementing a big fix or making a
backward compatible change. But when proposing a backward incompatible
change, I make sure to warn all users that I can find.

> > 2- No, there was never a requirement that defsystem should only be used
> > within a .asd. Actually, the test system relies heavily on the opposite.
> > The requirement is that .asd files be loaded in the correct context, by
> > load-asd -- notably, the correct *package* must be bound, the correct
> > readtable, etc.
>
> Unfortunately, DEFSYSTEM is the only entry point we can check.  So if
> LOAD-ASD is important, that's the only place I can check it. What else
> would you have me do?  Check *load-truename* for "asd"?
>
> Look, if you want to push this, then you can't object to my enforcing
> it.  If you don't want to push this, then we should make sure DEFSYSTEM
> works outside the context.  But I don't want to field bug reports where
> someone says "I tried to define this system and it didn't work," and
>
> In the olden days, we relied on programmers to make sure that the
> context for DEFSYSTEM reading was appropriate.  That was a pain for them
> sometimes, but it was clear, and it kept ASDF simple.
>
> At some point, ASDF decided to take on the burden of establishing the
> context for DEFSYSTEM reading.  OK, not my choice, but a reasonable
> decision.  But I flatly refuse to maintain *both* the DWIMing in
> LOAD-ASD *and* DEFSYSTEM execution in arbitrary contexts.  And as a
> programmer, I don't want ASDF to let me evaluate a DEFSYSTEM form only
> to beat me up because some invisible context, only apparent through
> reading the code, means that it doesn't work.
>
> Pick one, DWIMing, or freestanding execution, but you get only one.
>
There too I don't understand your reasoning. Who are you helping, and who
are you harming?

There always was a constraint on loading a .asd, and never was one on using
defsystem. We can assume that all software that works fits those
constraints, but might not fit tighter ones. Why make it harder to use
defsystem? What would you check exactly?

To me, setting the syntax context is an essential service to provide to
whoever writes a .asd file. The .asd maintainer cannot assume anything
about the syntax context used by the user, who may not control the syntax
context from the end-user. If you can't even trust the package or
readtable, or character encoding, you can't even write code that has any
guaranteed meaning. Note that it's called .asd rather than .lisp for a good
reason: it's Lisp code, but supposed to run in a specific context.

I don't see who is served, or what feature is enabled, by introducing this
backward incompatibility.

> > On Fri, Sep 23, 2016, 09:49 Robert Goldman <rpgoldman at sift.net
> > <mailto:rpgoldman at sift.net>> wrote:
> >
> >     I have been working on enforcing assumptions recently added to the
ASDF
> >     docs.  Specifically, that OPERATION instances only be created by
> >     MAKE-OPERATION and SYSTEMs only be parsed inside LOAD-ASD.
> >
> >     I should have a merge request up for review soon, but find that it's
> >     more tricky than I expected, because we don't even play by the rules
> >     ourselves!  Specifically, there are calls to MAKE-INSTANCE on
OPERATIONs
> >     in the ASDF codebase itself.
> >
> >     Cheers,
> >     r
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20160923/413ed5c3/attachment-0001.html>