[Asdf-devel] syntax control

Robert P. Goldman rpgoldman at sift.info
Thu Apr 3 01:06:20 UTC 2014


Faré wrote:
> compile-file and load already bind *readtable*, which means that for
> asdf itself to bind *readtable* should be a no-op in the common case,
> and a BIG save for those who want to switch the readtable at the REPL.

I'm puzzled by this claim.  As actually implemented, this seems to me to
tend to *force* procedural interaction with the *READTABLE*, in ways
that you deplore.  But perhaps I misunderstand your proposed revision.

If the programmer wants his/her changes to the readtable to persist over
a session, in the absence of an easy way to switch readtables (e.g., by
named-readtables and a READTABLE: head-of-file directive as there is in
ACL's ELI, and I believe there was in Zmacs), there isn't a pleasant
alternative to destructively modifying the value of *READTABLE* that
will be carried over multiple calls to COMPILE-FILE and LOAD.

But my understanding of your proposal is that you will somehow bind the
readtable to a *clean* readtable, rather than the current readtable, so
the behavior you propose will be radically different from the behavior
specified by the standard.  Is that not so?

Consider the case where there's no ASDF (as at the time of the CL
standardization), and no named-readtables.  What's the programmer to do
aside from picking a readtable and mangling it?  I suppose the
super-wizard could switch back and forth, but nothing in the spec seems
to make this at all pleasant.  In practice, my experience is that if,
e.g., you were working in Nisp, you just switched to the Nisp readtable
for your whole session, and that was it.  So the Nisp system definition
would copy the readtable, change *READTABLE* to point to the copy, and
then following systems (which would be written in Nisp, rather than
vanilla CL), would get the readtable in a smooth way.

Also, COMPILE-FILE binds the readtable to the *current value* of the
readtable.  This lets us copy it if we want, but given that the behavior
of SET-MACRO-CHARACTER is to destructively modify its readtable argument
(which may be *READTABLE*), I don't see that this gives any precedent to
the proposed syntax hygiene.

If COMPILE-FILE bound *READTABLE* to a *COPY* of the current readtable,
then I would see the precedent, but as it is, I'm still not convinced.

Indeed, I am only more convinced that the proposed behavior is a
departure from the current practice, and so should be signaled by some
expressed desire for strictness, rather than being the default.

Note that I'm not arguing that syntax hygiene is a Bad Thing, only that
it's not vanilla CL, so should not be the behavior you get from vanilla
CL.  By analogy, hygienic macros are arguably a Good Thing, but we keep
CL macros unhygienic and make you GENSYM your way to hygiene if you want
it.  I could imagine a library that exports a hygienic variant of
DEFMACRO, but I couldn't imagine making CL:DEFMACRO hygienic by default.

Best,

r







More information about the asdf-devel mailing list