Skip to content
GitLab
Menu
Projects
Groups
Snippets
Loading...
Help
Help
Support
Community forum
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
Menu
Open sidebar
asdf
ilc2010
Commits
1f13e432
Commit
1f13e432
authored
Aug 26, 2010
by
Francois-Rene Rideau
Browse files
Started to rewrite the traverse bug section.
parent
c6b0d0ef
Changes
1
Hide whitespace changes
Inline
Side-by-side
main.tex
View file @
1f13e432
...
...
@@ -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
}
the
re was a notorious bug that meant tha
t
dependencies upstream of a composite
component
would not trigger recompilation of downstream components
.
In
{
\ASDFi
}
,
the
dependencies of a composite componen
t
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.
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
.
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment