Commit 9414c493 authored by Francois-Rene Rideau's avatar Francois-Rene Rideau
Browse files

Small remarks in comments.

parent 8ae1d366
......@@ -669,7 +669,6 @@ without being foiled by translated output locations.
\section{Fixing {\Large \traverse}}
\label{sec:bug-fixes}
% \rtof{Moved some material from the backward compatiblity subsection here,
% because they are really about bug fixing, and not about backward compatibility
......@@ -716,40 +715,51 @@ without being foiled by translated output locations.
((:file "file3")))))))
\end{verbatim}
\end{minipage}
\caption{Example system (from the {\ASDFii} test suite), illustrating the
module dependency bug.}
\caption{Example system illustrating the module dependency bug.}
\label{fig:moduleBugExample}
\end{figure}
One of the most important bugs we fixed in {\ASDFii}, one that illustrates the
limits imposed by by backward compatibility, and one indicative of
future issues in {\ASDF}, was a problem with dependencies involving composite
components (modules and systems).
In {\ASDFi} there was a notorious bug that meant that dependencies upstream of a
composite component would not trigger recompilation of downstream components.
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. 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.'' So, for example, if one wanted to
build a hash-table based on the contents of a module or a system, one could do that in the
{\perform} method for that composite object.
We have no doubt that this design decision seemed reasonable when {\ASDF} was
first built, but it has turned out to have many unfortunate ramifications. In
general, it conflates together ``actions done to operate on a composite that are
not actions on a component'' (let us refer to these as ``synergistic actions'')
One of the most important bugs we fixed in {\ASDFii},
%% What are we compatible with and why?
%% See lp#479522
one that illustrates the limits imposed by by backward compatibility,
and one indicative of future issues in {\ASDF},
was a problem with dependencies
involving composite components (modules and systems).
% 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.
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.
% ``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
``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.
% From there to end of section, I'm lost.
More specifically, because these synergistic actions are typically to be done
whenever a system is loaded, the \lisp{OPERATION-DONE-P} method for arbitrary
operations, would not work properly to indicate whether the operation had been
done for that composite, but only to indicate whether the \emph{synergistic
actions} had been performed.
done for that composite, but only to indicate whether the
\emph{synergistic actions} had been performed.
So, in {\ASDFi}, if one was to (compile and) load system
\lisp{test-module-depend}, touch \file{file2.lisp}, and then ask whether
\lisp{compile-op} had been done on module \lisp{quux} (containing \file{file2}),
......@@ -768,15 +778,16 @@ loading done to a module like \lisp{quux}. Unfortunately doing this in the
{\perform} is done \emph{after} the operation on the components, not
\emph{around} the operations on the components.
Trying to fix composite dependencies in {\traverse}, therefore, opened a big can
of worms. {\ASDFi} originally contained special-purpose, \textit{ad hoc}, logic
for modules to decide when their components needed to be operated on (since
\lisp{operation-done-p} could not be used), and this
Trying to fix composite dependencies in {\traverse}, therefore,
opened a big can of worms.
{\ASDFi} originally contained special-purpose, \textit{ad hoc}, logic
for modules to decide when their components needed to be operated on
(since \lisp{operation-done-p} could not be used), and this
special-purpose logic had some bugs.
Instead of radically re-engineering the logic, we simply repaired it in place
(and later {\fare} refactored it), fixing the bug illustrated in
Figure~\ref{fig:moduleBugExample} (which was taken from the {\ASDFii} test
suite).
Figure~\ref{fig:moduleBugExample}
(which was taken from the {\ASDFii} test suite).
We determined that we could not change the semantics of performing operations on
composites from synergistic actions to composite actions, without danger of
breaking an arbitrary amount of existing systems.
......
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