Commit 1f13e432 authored by Francois-Rene Rideau's avatar Francois-Rene Rideau
Browse files

Started to rewrite the traverse bug section.

parent c6b0d0ef
......@@ -722,32 +722,40 @@ involving composite components (modules and systems).
%% See lp#479522
It illustrates both design issues in {\ASDF}
and limits imposed on us by backward compatibility in solving those issues.
and one indicative of future issues in {\ASDF},
However, ours was a partial fix, and we will have to tackle
a full solution in the future.
% Why introduce name ``composite'' instead of just telling that systems are modules?
In {\ASDFi} there was a notorious bug that meant that
dependencies upstream of a composite component
would not trigger recompilation of downstream components.
In {\ASDFi}, the dependencies of a composite component
would fail to trigger recompilation of that component
and its dependents (the components that depend on it).
Figure \ref{fig:moduleBugExample} gives a system that shows the bug.
If one were to load this system, then modify \file{file1.lisp},
that would \emph{not} cause \file{file2.lisp} or \file{file3.lisp}
to be recompiled when reloading system \lisp{test-module-depend}.
The problem arises because composite components
are not like other {\ASDF} component classes.
are not like other, simple {\ASDF} component classes.
% ``Never ascribe to decisions what can be ascribed to lack thereof.''
In the original design of {\ASDF},
the decision seems to have been made that
to {\perform} an operation on a composite component
was to mean ``perform additional operations on that composite'' rather than
``perform the operation on the composite as a group.'' % This whole sentence is so unclear!
So, for example, if one wanted to build a hash-table
based on the contents of a module or a system, % why would you?
one could do that in the {\perform} method for that composite object. % uh?
We have no doubt that this design decision seemed reasonable
when {\ASDF} was first built, % was it?
but it has turned out to have many unfortunate ramifications.
In general, it conflates together
{\traverse} would generate a plan made of elementary steps,
each a pair of {\operation} and {\component},
that are to be {\perform}ed in sequence.
Whereas the {\traverse} method for a composite component recurses into
the constituents of the composite,
the step for composite component itself is scheduled to occur
after all its dependencies and constituents have been
suitably compiled and loaded;
performing that step does nothing,
scheduling it is just a way to
prevent recursing into it more than once.
This design did fit the original {\ASDF} goal of simplicity,
at least if by simple we mean that it uses sequences as chained cons cells
rather than implementing a new datastructure.
But it has turned out to have many unfortunate ramifications.
In general, it conflates the data of an operation and a component
as meaning either
``actions done to operate on a composite that are not actions on a component''
(let us refer to these as ``synergistic actions'') % what does that mean???
and ``the action of operating on a composite'' in ways that are unfortunate.
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment