On Sun, Jun 8, 2014 at 12:09 PM, Robert P. Goldman rpgoldman@sift.info wrote:
Faré wrote:
On Sat, Jun 7, 2014 at 8:03 PM, Robert P. Goldman rpgoldman@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]
OK, so the bug is not that systems leak the readtable *out*, it's that readtables leak *into* systems. I had not understood that.
So unlike *PACKAGE*, the current (REPL) value of *READTABLE* leaks into every system that you load. It seems to me that this is a deficiency in CL: if CL had an IN-READTABLE equivalent to IN-PACKAGE, we would not be having this discussion.
Oh, the outer *package* also leaks in, but people have the discipline to use defpackage and in-package, and to not shadow them away in incompatible ways.
The syntax-control branch ought to *also* set *package* to *shared-package* which should be cl-user for maximum backward compatibility, and asdf-user or something like that for maximum portability. Or maybe, like Stelian once suggested, some package that *only* has defpackage and in-package defined (maybe also uiop:define-package?), for maximum strictness.
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
This is the one I had in mind, and this is the one I don't think is ASDF's problem. If x1 exported *X1-READTABLE* and ADD-X1-SYNTAX (this function adds X1 reader macros to an existing readtable passed as argument), then the Right Thing would simply be for X1 not to alter the global readtable, and for X2 and X4 to explicitly employ the readtables they want.
This problem does not seem worthy of fixing in ASDF.
Indeed, and I'm not proposing that ASDF should do anything about it. I'm just explaining what the restriction *already is* for sane programs to never define or use conflicting readtable modifications. This restriction had to be documented (which I did with ASDF 3.1).
Scenario A seems like a stronger argument, but I'm inclined to say "instead of limping along with a complex fix in ASDF, let's just push NAMED-READTABLES use and leave ASDF alone."
NAMED-READTABLES seems like a much better fix than complicating ASDF further, because it gets at the root of the problem, instead of band-aiding around it.
The counter-argument, I suppose, is that Scenario A can only be fixed if *EVERYONE* fixes their code to put IN-READTABLE at the top of their source files, just the way we have to put IN-PACKAGE at the head of every source file.
Exactly. Unless you're demanding that every library should depend on named-readtables and use it, that doesn't work. And even then, you'd forbid any readtable that is incompatible enough with the standard one to interfere with the evaluation of the in-readtable form, e.g. a readtable for Python syntax, etc. — or even something as innocuous as fare-quasiquote, if a file uses ` before in-readtable.
This can't fly. And named-readtables itself can't depend on named-readtables. In the end, you'd have to move it into ASDF, which is more complex than the simple use of *shared-readtable*.
My question here came from thinking only about your Scenario B, and overlooking Scenario A.
I'm starting to reluctantly come around, but I still need to figure out how my system went up the spout when using syntax-control ASDF. If I can't answer on my own behalf, I can hardly claim to understand the patch well enough to apply it....
If I can help with this understanding, I'm at your service to inspect code of discuss behavior.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Guns & bullets don't kill people — blood loss and organ damage kills people.