Enforcing assumptions

[Robert Goldman]

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."

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?

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.
> 
> 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.
> 
> 
> 
> 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
>