On 28 Mar 2014, at 19:00, Robert Goldman rpgoldman@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