[asdf-devel] Make the CL syntax predictable

[Felix Lange]

On 28 Mar 2014, at 19:00, Robert Goldman <rpgoldman at sift.net> wrote:

> I would be much happier to see this conversation direct itself towards a
> design for providing strict mode, rather than arguing about whether or
> not "strict mode" should be universally imposed.  I will say it again:
> that will not happen.

Robert, I really like your idea of a strict mode of ASDF that isolates a
single system from global state changes.

While reading the thread, a funny analogy found its way into my head:

To some degree, the isolation feature is similar to a network firewall.
Strict mode could work like a firewall config, where one would specify a rule
for allowed state changes (both inbound and outbound) in the system definition.

This is just a rough draft of what it could look like for the ASDF user:

    (defsystem "my-app-system"
       :isolation (
                   ;; this system modifies the readtable
                   (:export :readtable)

                   ;; import changes made by my-base-system
                   (:import :all "my-base-system")

                   ;; use readtable changes made by dependencies
                   (:import :readtable :dependencies)

                   ;; use global declarations
                   (:import :declarations)

                   ;; catch-all rule: isolate against any other changes
                   (:deny-export :all)
                   (:deny-import :all)
                  )
       :components ...)

For backward compatibility, the default rules would allow any state to be
exported or imported. In order to make the build deterministic,
rule violations should throw a condition (failing the build).

If the isolation option can be applied to any component, it would even be
possible to isolate individual source files/directories in a system
against each other (although it would be kind of ridiculous if anyone
ever did this in practice).

It might also be feasible to allow external overrides/extensions for the
rules defined by the systems. This way, the person responsible for build
issues at e.g. ITA could maintain total control of the side effect propagation
without modifying the system definitions themselves.

I believe that given some development effort, a lot of things can be
made controllable by this rule model. Things that come to mind right now
are printer variables, reader variables, declarations and maybe even
package locks, but I'm sure there's even more to it.

I agree with Faré about the fact that it's OK if this feature works
only when using ASDF to compile systems. Anyone who wants to use this during
interactive development with SLIME will need to use SLIME's ASDF integration.

-f