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