[Asdf-devel] syntax-control branch

[Robert P. Goldman]

Faré wrote:
> Being able to support most code that change the readtable is worth it.

I think part of the problem here is that you are smarter than most of
the rest of us (at least me).

I'm still groping after a clear statement of exactly what class of bugs
it is that we are proposing to fix.  The existing design document is
still too vague, proposing to fix

"uncontrolled, unintentional leaking of readtable side effects to
systems that depend on such effects not happening,"

I think we need a clear example of a bug (ideally from a real system,
although it's fine if that bug has since been fixed) that would be fixed
by the change.

Also, we need an argument for why this must be fixed in ASDF.

Here's the devil's advocate argument:

"OK, you have a crummy library that leaks state unintentionally, and
happens to do that in the readtable.  Why is it ASDF's job to make that
library suddenly work *without modification*?  Why shouldn't we just
tell the maintainer of that library to stop leaking state unintentionally?"

E.g., if I had a library that was annoyingly causing the printer to
display integers in hex, why wouldn't I just fix that in the library,
instead of trying to hack ASDF to prevent it from happening?  The
GBBopen library, which makes a sort of expert system shell, was borking
my environment in all sorts of ways, but I just stomped on it until it
stopped doing that.

A further development of the devil's advocate position:

It's not hard to fix unintentional readtable leakage.  You just make
your library export a variable holding its readtable and a function that
will set the readtable to the one you're exporting.  You make sure you
don't touch the default readtable.

On the flipside, if you have a library that is intentionally leaking
readtable state, it's likely to be an intricately balanced, teetering
and delicate edifice, because CL doesn't provide good tools to deal with
readtables (as we have discussed, packages have names, so are easy to
deal with; readtables don't and are correspondingly fussy). So if we go
in there using ASDF as a blunt instrument, we are very likely to mess
things up in complex and difficult to debug ways.

So it seems to me that we are making a complex extension to ASDF to fix
problems that are easy for library maintainers to debug, and can have
side effects that will be difficult to debug.  That doesn't seem like a
good cost/benefit tradeoff.

I'm willing to be persuaded, but I need an "elevator pitch" that
addresses these issues head on.
* What exactly are we fixing? and
* Why is ASDF the right place to fix this? with the correlate
 * Isn't an ASDF fix more complicated than just making libraries that Do
The Right Thing?

Again, I'm not dead set against this, but I just don't Get It yet.

thanks,
r