[asdf-devel] Make the CL syntax predictable

[Robert P. Goldman]

Here is an example of a kind of system that will be broken by this
proposed change:

* We have a distributed system that is lisp-based.

* There is a small set of ASDF systems that constitutes the common base
of the modules of this distributed system.

* For each module, there is an ASDF system, which incorporates the
common base, the module proper, and possibly some additional systems.

* The common base has a readtable (and it may have a PPRINT-DISPATCH-TABLE).

* The distributed modules systems assume, safely, that the readtable
will be set by the common base.

* Code in the common base uses readtable-setting functions with the
default values for the readtable.

As I understand it, the proposed change will break this kind of system.
 Indeed, I think it's likely to break the parent common base system as
well as breaking the system composition (the use of the readtable is not
confined to a single file in the common base, and I believe it straddles
multiple subsystems, which are represented as individual ASDF systems).

I'm not going to defend the structure of this code, but I strongly feel
that it is not the job of ASDF to impose a personal opinion that this
coding pattern is bad, and should be *forced to break* when previously
it worked perfectly adequately.

To the best of my knowledge, the readtable manipulation functions in CL
don't provide any easy replacement for the pattern of coding applied here.

Yes, one *can* set a global to the special readtable, and then one can
write a special PERFORM method (one? or many?) that will bind
*READTABLE* to the value of this global.

This is already a monumental PITA, since the PERFORM method will have to
refer to a variable named in a package that doesn't exist at the time
the ASDF system is defined.  It also forces our poor programmer to know
more than s/he ever wanted to know about ASDF, and IMO inappropriately
bleeds details of the code of the system into the system's build file.

I believe that the proposed hygiene practice *also* leaves the
programmer in an uncomfortable position if s/he incrementally compiles
functions inside an editor buffer, since the readtable will not be
properly set.  I.e., AFAICT, although careful binding of the readtable,
rather than treating it as a global variable, feels like the Right
Thing, it has undesirable consequences because we don't have good ways
to bind the readtable around the editor.  If a -*- READTABLE: foo; -*-
file header worked, this would be less of a concern, but using a header
like that requires named readtables.

My conclusion is that enforcing some sort of compartmentalization of
readtable is not only an inappropriate imposition of a particular style,
but *also* means we are hanging the poor programmer out to dry.  CL
simply doesn't provide good tools for manipulating the readtable in the
way we are proposing to enforce.

IMO, named readtables are the way to go, but they are not a common
feature of the language, and the portable library is bit-rotted.*

I will not be pushing this proposed modification into the next release,
and it will take a lot of convincing for me ever to incorporate it into
ASDF.

Best,
r

*This is partly my fault, but the current disarray of cl.net, the
library's position as part of an abortive EDITOR-HINTS master system,
and the previous maintainer's putting it into a revision control system
(darcs) that I don't use and don't understand are additional
contributing factors.