Faré wrote:
On Fri, Mar 14, 2014 at 6:10 PM, Robert Goldman rpgoldman@sift.net wrote:
Quick follow-up: what about blowing this discussion into launchpad under the rubric of "Manage CL syntax" or something like that.
I would prefer not to lose the discussion.
I believe this is a place where a tool like POIU or XCVB really veers away from vanilla CL usage.
Vanilla CL usage encourages* actions during building that side-effect the global state of the image. These actions may be bad if one wishes to build individual components in multiple different CL images. But they are natural to people developing code incrementally and interactively using a REPL.
I don't want ASDF to drift into being a tool that prescriptively moves people away from that practice. I think that's too presumptive for a piece of infrastructure. I don't think it's my job to wreck code, just because it's bad style. And I don't think proper use of the readtable or of pretty-print dispatch is obvious enough that people will recover well if we mess with it.
As you have said, I am inclined to be much more conservative about changes like this.
Here is my theory: safe code needs to respect hygiene, because you never know which system are loaded before or after: it depends on the overall plan of the toplevel target system. Therefore is it never correct to rely on other systems having set a particular readtable, and it is never correct to side-effect the current readtable into something that modifies standard characters — or any character that any other program might want to use, for the matter. If you side-effect the readtable, and the readtable escapes, you are going to hurt someone, somewhere.
In the current setup, it is therefore a bug if you side-effect the readtable, and those programs that do are buggy. Using named-readtables is fine, but only if you reset the readtable to the standard one at the end of every file, or have a method that binds *readtable* around your compilation.
I see two ways forward: (1) recognize that it is a bug, and help programmers by being strict, modulo some compatibility mode for older systems until they are fixed, or (2) slightly change the semantics so that it's not a bug anymore, by making the readtable either per-file or per-system; then you can modify the readtable to your heart's content, because it's private.
My initial reaction was (1), and that's more or less the patch I sent to anton, who tells us it breaks a lot of things. At Anton's suggestion, I considered (2) and it looks promising — but we need to modify the protocol and/or use a new method-combination to achieve the effect in a backward compatible way.
No, we cannot do either (1) or (2).
CL does not say it is a bug to rely on an upstream-loaded file to set the readtable to a value that you expect. So breaking code that makes that assumption by forcing file-scoped readtables and pprint dispatch tables on the programmer is not an OK thing for us to do.
It's not ASDF's job to break code that we consider to be bad code.
The CL spec went out of its way to *permit* the code that you are arguing to be buggy. They *could* have demanded a readtable argument, but they did not. They could have imposed a scope on readtables, but they did not.
Furthermore, we are not omniscient: the programmer could knowingly count on a non-file-scoped READTABLE in a way that s/he knows is safe, because s/he can prove to him/herself that *READTABLE* will be properly bound at all locations in the code. That information could be perfectly correct, but invisible to ASDF. We should not break such code.
Making constructs file-scoped willy-nilly is not something that ASDF should do. In my opinion, it's overreach.
To analogize: that's a job for lint, not a job for make.
Best, r