Hi! My 2 cents (a draft for a proposal).
1. As I said, there should be a way to set up tracing and maybe assertable preconditions that should hold before loading the system. This way we can _diagnose_ what happens. This technique should be supplied not for newer versions only, but for some old versions too, so that one can compare the state before and after the change, and all should be documented. I believe trace and CLOS should suffice to avoid patching asdf sources for old versions, but if not, patches can also go.
2. By default, bind readtable to (copy-readtable *shared-readtable*) or (copy-readtable nil) before loading each system (I hope that systems are loaded continuously, that is, components of one system are not intermitted by components of another, otherwise we would do that at a component granularity). Obviously, it would break some setups.
3. If system wants to do something special, that special must be declared. Obvious special behavior is not to copy current readtable before loading system - in this case all changes would affect global readtable. One can think that another option is to use some named readtable, but we don't need that: one can specify readtable on a per-file basis (in fact, currently there should be no more than one readtable per package).
4. For any additional declarations and settings, there should be a way to declare them either in system definition itself, or in some another place which is read before system is loaded (some per-site asd configuration). This is for inserting declarations into unmaintained 3-d party systems.
Does that work? I guess no due to some reason, but I'm not an ASDF expert, so I can be optimistic :)
5 (offtopic) there is a perfect solution for macro-character conflict, which is a plain (non breaking) extension of CL. It is named symbol-readmacros. I use them for several (maybe 7) years already, and they just work. No pain anymore :) The idea is that macro reader is associated to symbol, not to character. This way issue of conflicting characters is reduced to that of conflicting symbols. We all know that issue of conflicting symbols is resolved by package prefixes, import, use-package and so on, so many implementations of custom this-lib:{ and that-lib:{ can coexist peacefully in the same image. Of course, any client code should be modified to take the advantage of this, so I usually add couple of lines for every library I use that wants to extend syntax.
I'm not sure it can be implemented in a portable way or even w/o changes to the implementation, but I have the implementation for SBCL and at some time in the past I had one for LW.
I believe this symbol-readmacros is the only right thing here. There are thousands of libraries and only dozens of characters which can be used. So when using macro-characters, conflicts are absolutely inevitable.
2017-10-13 23:31 GMT+03:00, Faré fahree@gmail.com:
Due to the readtable bug in ASDF 3.3.0 I updated the "syntax-control" branch that for the last three years was supposed to solve all readtable bugs when building with ASDF.
I merged 3.3.0.1 into the branch, but the branch itself is not ready for merging into master: it does either too much or too little, and must be either completed or simplified. I think it stands a better chance of bieng merged soon if it is simplified, so I re-read and re-wrote the documentation for what this branch should be doing, and detailed a "Proposal 1" for minimal changes to ASDF that would go a long way towards bringing sanity in builds of software that modify the syntax.
I sollicit your feedback: https://gitlab.common-lisp.net/asdf/asdf/blob/syntax-control/doc/syntax-cont...
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Problem of the day: finding suction cups that don't suck.