On Sat, Jun 7, 2014 at 8:03 PM, Robert P. Goldman <rpgold...@sift.info> wrote: > 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. > I probably should create test cases.
Scenario A: dealing with *readtable* being bound to a new value 1- setup the test environment 2- save current packages 3- load fare-quasiquote (or anything that has its own readtable) 4- while in-readtable fare-quasiquote, load-system :force t something that uses normal quote, and see it corrupt its fasl with fare-quasiquote annotations. 5- delete all new packages since 2 6- repeat 3, 4 — and see whether it breaks [used to] Scenario B: dealing with the *readtable* object being modified 1- setup the test environment 2- load and compile x1, that define #^ 3- load and compile x2, that uses #^ as per x1 4- load and compile x3, that defines a different #^ 3- load and compile x4, that uses #^ as per x3 4- force recompilation of x2 — it will use the definition from x4 — oops 5- force recompilation of x1 and x4 — it will use the definition from x2 — oops again > Also, we need an argument for why this must be fixed in ASDF. > Because ASDF must be safe when called from a different readtable. And using ASDF safely in presence of > 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?" > It's not *that library*. It's all the innocent libraries that know nothing about readtables, and that will be compiled into calls to functions from systems they don't depend on, which will pollute the build. > 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 j > Because you can't. You can't control what readtable is used at the REPL. You don't control which of your dependencies will or won't be forced recompiled by some change. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org No one has the right to a position; everyone has the right to positions being well filled. — Ernest Renan ust 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 > _______________________________________________ Asdf-devel mailing list Asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
