[asdf-devel] Make the CL syntax predictable

Faré fahree at gmail.com
Sun Mar 16 05:17:25 UTC 2014

Dear Anton,

can you do a cl-test-grid test with the code in the standard-syntax
branch from git://common-lisp.net/projects/asdf/asdf.git
(commit 2c1107) ?

That branch has my "each system gets its own syntax" thing, based on a
general-purpose "each system has a set of private variables" protocol.
This protocol allows to designate variables using a string that will
be parsed later, but doesn't somehow try to canonicalize names — if
you use two different names for the same variable, you lose. By adding
:after methods to compute-system-variables, more variables can be
configured with configure-system-variable and
configure-system-variables — this makes it a good basis for some
future out-of-band configuration of ASDF, though such mechanism would
need to be part of ASDF itself, or loaded early via an ASDF init file
of some sort to be effective. Some DSL could then specify variables to
include in a system's private variables, with optional initial value,
depending on the name and version of the system and on various
features, with usual rules (or per-system rules?) to inherit or ignore
other configuration settings. Such a DSL is *not* included in this

This protocol itself uses a new call-with-action-context protocol that
perform-with-restart calls around perform. This is mostly backward
compatible, except that existing clients who call perform directly
(rather than perform-with-restarts) might miss those around methods —
to get that effect we'd need a new method combination. swank-asdf
would notably need to call perform-with-restarts instead of perform,
and if possible to enable the try-compile-file-with-asdf hook function
by default.

I tested it to correctly process ironclad, at least.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Gods don't kill people. People with Gods kill people. — David Viaene

More information about the asdf-devel mailing list