[asdf-devel] Make the CL syntax predictable

[Robert P. Goldman]

Faré wrote:
> On Fri, Mar 14, 2014 at 6:10 PM, Robert Goldman <rpgoldman at 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