[asdf-devel] Make the CL syntax predictable

[Robert P. Goldman]

Faré wrote:
> The clean thing to do would be to use named-readtables and/or
> cl-syntax, and have each file evaluate (in-readtable :foo) or have a
> perform :around method or around-compile hook that does it for you.
> 
> We could also support your doing (in-readtable :foo) only once for the
> entire system, though it's trickier.
> 
> (Question, either way: how does the readtable get re-initialized (or
> not) when you recompile a modified system? Should you start from a
> fresh readtable every time, or reuse the readtable of the end of
> compilation while at the start of compilation?)
> 
> But polluting arbitrary systems loaded after you is definitely a bad
> idea: if someone else write a system that depends on part of yours,
> that also depends on unrelated systems, these unrelated systems will
> end up being affected by your readtable changes, and, if they are just
> as "dirty" as yours, they might in turn affect your system.

The problem with this claim is that you are imposing a single model of
ASDF usage on the community.

"Polluting arbitrary systems after you" is *not an issue* in the use
case I presented.

That system is an in-house system, and it NEVER ENCOUNTERS arbitrary
systems after it.  It *knows* what systems are going to follow it, and
it sets up for those systems entirely correctly.

I am going to resist this change because it assumes that the open source
library world is the only use case for ASDF.

That is simply not the only use case.  The example I have exhibited
shows a case where the authors of the system are INTENTIONALLY, and
CORRECTLY side-effecting the global state.

You may not like it, but it's not your place to break it.

I feel like you are assuming that the only use case for ASDF is to
maintain *libraries* (as opposed to systems) that are to be composed
with arbitrary other pieces of software.

That's not the only use for ASDF, so we shouldn't force that pattern on
users.

You say:

"It did not work "perfectly". It happened to work because you control
the build process to make sure you don't interfere with other systems,
and ASDF de facto imposes on general purpose libraries that they can't
safely do anything fancy with readtables, which sucks."

I don't agree.  What I would say is "you are going to break my code in
order to allow it to compose safely with other systems -- something that
it will NEVER be called upon to do."

AFAICT, you are contravening your own principle here:

"People who were previously leaking readtable state will have it
private to their system;
if they were leaking readtable state from one system to the next, that
won't work anymore,
but that was already a hazard to systems they were not writing,
so we're trading a "that's not working for another poor sod
who can't know and can't do anything about it"
to a "that's not working for someone doing something ugly
who should know better and can do something about it".
And that was the guiding principle of ASDF2:
"he who knows is who specifies the information, he who doesn't know
doesn't have to do anything"."

This is a case where the authors of the system are in a position to know
that what they are doing is correct, and you propose to break their code
in order to force them to support a non-existent use case.  WE know that
these systems -- which no one outside our firm will ever encounter --
work correctly.  You are proposing that ASDF say "sorry, that's not good
enough, since that wouldn't work if you put your code in Quicklisp."
This code is no "hazard to any systems that [we] were not writing" but
you propose to break it anyway.

The bottom line:
I am not going to accept a patch that does this.


Yours sincerely,
R