That's why, for example, we have systems that bleed readtable across their boundaries: the systems really aren't stand alone entities, but limitations on ASDF expressiveness, and the desire to get more modularity than the (necessarily in-line) :MODULE will permit, causes a proliferation of systems that are NOT libraries, and have meaning only in context.
I'm not going to move ASDF towards breaking such systems.
Robert, this is how i see it reading this thread:
- you know at least about one big and complex codebase with many asdf systems, where isolating *readtable* would break it and cause a lot of work/headache that is hard to debug, especially if the codebase doesn't compile free of warnings to begin with. this headache would probably be yours in case of this system.
- to Fare (and to me, who have wasted precious hours due to this) readtable higiene clearly looks like a major improvement when looking at it objectively, so much so that somewhere down the road breaking systems that now break other systems (by modifying the global readtable) is acceptable. my impression is that you would also agree with this if the legacy was not pulling your back.
*if* this is the case, then why not accommodate for such legacy systems/use-cases simply by e.g.:
;; force upgrade (asdf:load-system :asdf)
;; optionally, for extra safety (asdf:load-all-dependencies-of :my-legacy-system)
(setf asdf:*readtable-higiene* nil)
(asdf:load-system :my-legacy-system)
and then we can have our cake and eat it too...
(alternatively a new system class could be introduced and all legacy systems could specify a :class "hu.dwim.asdf:hu.dwim.system", just like we need to do currently for self-defense purposes against e.g. readtable polluters and against we polluting the readtables.)