Commit d714825e authored by Robert P. Goldman's avatar Robert P. Goldman
Browse files

Proposed introduction.

parent 0b1eb4a9
......@@ -121,23 +121,34 @@ Common Lisp, build infrastructure, interaction design, code evolution, dynamic c
{\ASDFii} is the current version of {\ASDF},
``Another System Definition Facility'' \cite{ASDF-Manual}.
{\ASDF} allows {\longCL} ({\CL}) developers to specify
how to build their software from components,
a task for which C developers would typically use {\make}.
% \rtof{
% With all due respect, I don't believe that ASDF /is/ really fully
% analogous to make, for reasons I have articulated before --- ASDF operates on
% a running image, whereas make operates on the file system. Also, ASDF is a
% build {\em planner} rather than simply a builder. IIUC make does no lookahead. }
% \ftor{
% I drive the build of tests and documentation with make, too.
% as for the running in an image and planning in advance, I count that as
% internal implementation details, especially since, having implemented the
% rival XCVB and its ASDF compatibility/conversion mode, I don't think they
% are essential to the concept at hand. But the discrepancies do deserve
% mentionning, and that's precisely what the sentence below does: }
However, whereas {\ASDF} for {\CL} is analogous to {\make} for C
from the point of view of the social purposes it serves,
its internal technical structure is very different.
how their software should be built from components,
and how it should be loaded into the current lisp image.
Using \CLOS{}, \ASDF{} can be extended to accommodate operations other than
compiling and loading, and components other than \CL{} source files and modules.
% and to load this software into their lisp images.
% a task for which C developers would typically use {\make}.
% % \rtof{
% % With all due respect, I don't believe that ASDF /is/ really fully
% % analogous to make, for reasons I have articulated before --- ASDF operates on
% % a running image, whereas make operates on the file system. Also, ASDF is a
% % build {\em planner} rather than simply a builder. IIUC make does no lookahead. }
% % \ftor{
% % I drive the build of tests and documentation with make, too.
% % as for the running in an image and planning in advance, I count that as
% % internal implementation details, especially since, having implemented the
% % rival XCVB and its ASDF compatibility/conversion mode, I don't think they
% % are essential to the concept at hand. But the discrepancies do deserve
% % mentionning, and that's precisely what the sentence below does: }
% However, whereas {\ASDF} for {\CL} is analogous to {\make} for C
% from the point of view of the social purposes it serves,
% its internal technical structure is very different.
\ASDF{} has become the glue that holds the \CL{} community together. The vast
majority of {\CL} libraries are delivered with {\ASDF} system descriptions, and
assume that {\ASDF} will be present to satisfy their own library dependencies.
\ASDF{} has taken that role because of they way it simplifies not just the
building and loading, but also the installation of \CL{} libraries.
In the past few years, many in the {\CL} community
have expressed a discontent at the current state of {\ASDF}.
......@@ -161,7 +172,7 @@ Shortly after this post,
Gary W. King, who was {\ASDF} maintainer,
resigned for lack of time resources,
and {\frr} took over the maintainership of {\ASDF}.
With the help of many Lisp hackers first of whom {\rpg},
With the help of many Lisp hackers (including the second author),
he developed {\ASDFii}:
in addition to many technical bug fixes,
{\ASDFii} tries to identify social problems
......@@ -173,26 +184,28 @@ that reduces problematic interactions.
In this paper we discuss a number of interesting technical and social challenges
that we had to face while developing the new version of {\ASDF},
and the lessons we learned.
%\fixme{Add a note to say that we didn't just plunge in and change everything.}
\fixme{Before submission make sure we update the roadmap.}
The paper is divided in several sections.
After this introduction comes
a presentation of what {\ASDF} does and how it does it.
Then we explain the essential yet non-functional changes we made
to achieve the hot upgrade of {\ASDF} code.
Next we discuss the semantic changes we made to the user-visible API,
extensions and restrictions.
Thereon we discuss how software engineering best practices
applied to our endeavour.
Finally, we explain how our software relates to other efforts
and briefly discuss possible future improvements.
As an appendix to the paper,
we describe the role of {\ASDF} in the Common Lisp community
and say a few words about its history;
we also give a brief summary of its design and function,
so that the reader may have a clearer understanding of
the technical discussion.
The social issues arose from the central role of \ASDF{} --- we were determined
not to ``break the community'' with the introduction of \ASDFii{} --- and
imposed many technical challenges. One of the most interesting technical
challenges was to develop a portable means to hot upgrade for \ASDF{}, as
discussed above.
In the immediately following section, we introduce \ASDF{}, explaining
what it does and how it does it. We believe this material will be of interest
not just to those who have never used \ASDF{}, but even to experienced users,
since experience has shown us that there are several aspects of \ASDF{} that run
counter to the intuitions of its users.
We begin the main technical content with a section discussing
the hot upgrade of {\ASDF} code, since solving this problem was the
\textit{sine qua non} for the very existence of \ASDFii{}.
After that, we discuss the semantic changes we made to the user-visible API,
most of which had to do with improving the way \ASDF{} is configured so that it
can find its input systems and place its output products (notably compiled code).
In the following section, we discuss how software engineering best practices
applied to our endeavor, after which we discuss one of the most tricky bug fixes
(repairing the cornerstone \traverse{} function).
We wrap up with a discussion of related work, suggestions for future
improvements to \ASDF{}, and a brief conclusion.
\input{asdf}
......
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