Here is an example of a kind of system that will be broken by this proposed change:
* We have a distributed system that is lisp-based.
* There is a small set of ASDF systems that constitutes the common base of the modules of this distributed system.
* For each module, there is an ASDF system, which incorporates the common base, the module proper, and possibly some additional systems.
* The common base has a readtable (and it may have a PPRINT-DISPATCH-TABLE).
* The distributed modules systems assume, safely, that the readtable will be set by the common base.
* Code in the common base uses readtable-setting functions with the default values for the readtable.
As I understand it, the proposed change will break this kind of system. Indeed, I think it's likely to break the parent common base system as well as breaking the system composition (the use of the readtable is not confined to a single file in the common base, and I believe it straddles multiple subsystems, which are represented as individual ASDF systems).
I'm not going to defend the structure of this code, but I strongly feel that it is not the job of ASDF to impose a personal opinion that this coding pattern is bad, and should be *forced to break* when previously it worked perfectly adequately.
To the best of my knowledge, the readtable manipulation functions in CL don't provide any easy replacement for the pattern of coding applied here.
Yes, one *can* set a global to the special readtable, and then one can write a special PERFORM method (one? or many?) that will bind *READTABLE* to the value of this global.
This is already a monumental PITA, since the PERFORM method will have to refer to a variable named in a package that doesn't exist at the time the ASDF system is defined. It also forces our poor programmer to know more than s/he ever wanted to know about ASDF, and IMO inappropriately bleeds details of the code of the system into the system's build file.
I believe that the proposed hygiene practice *also* leaves the programmer in an uncomfortable position if s/he incrementally compiles functions inside an editor buffer, since the readtable will not be properly set. I.e., AFAICT, although careful binding of the readtable, rather than treating it as a global variable, feels like the Right Thing, it has undesirable consequences because we don't have good ways to bind the readtable around the editor. If a -*- READTABLE: foo; -*- file header worked, this would be less of a concern, but using a header like that requires named readtables.
My conclusion is that enforcing some sort of compartmentalization of readtable is not only an inappropriate imposition of a particular style, but *also* means we are hanging the poor programmer out to dry. CL simply doesn't provide good tools for manipulating the readtable in the way we are proposing to enforce.
IMO, named readtables are the way to go, but they are not a common feature of the language, and the portable library is bit-rotted.*
I will not be pushing this proposed modification into the next release, and it will take a lot of convincing for me ever to incorporate it into ASDF.
Best, r
*This is partly my fault, but the current disarray of cl.net, the library's position as part of an abortive EDITOR-HINTS master system, and the previous maintainer's putting it into a revision control system (darcs) that I don't use and don't understand are additional contributing factors.