Dear Robert & asdf-develers,
I was discussing max version constraints and the havoc they wroke on
Haskell land, yet the legitimate use they have in toplevel projects
integrating many libraries, and figured that maybe the solution could
be a difference in treatment between max version constraints found in
a toplevel asd file (the one you directly call operate on) vs ones
found in subsequently loaded .asd files: a broken constraint at the
toplevel would cause an error, whereas a constraint broken outside the
toplevel would only issue a warning—a warning that would suggest
either removing the constraint (because its value outside the toplevel
is dubious or advisory only) or updating it (since the toplevel works
without it), or adding it to the toplevel too (because the toplevel
doesn't actually work without it). The warning can be hushed the usual
way if desired, and both the warning and error would inherit from a
common condition.
Technically, to implement this, the main methods of load-asd and
operate would bind a special variable to the path of the .asd file (or
its truename* ?) if the binding is currently NIL, and the constraint
checker would behave differently depending on whether the
component-path of the current system matches it or not. (This is a
rough idea that has not been tested.)
Would this solution work for you? It seems to me that it should make
everyone happy.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
“All problems in computer science can be solved by another level of
indirection.” — David Wheeler
