Commit 8ae1d366 authored by Francois-Rene Rideau's avatar Francois-Rene Rideau
Browse files

Some proofreading.

parent afbebde3
......@@ -48,13 +48,6 @@
Publisher = {Springer}
}
Article{XCVB,
Author = {Fran\c{c}ois-Ren\'{e} Rideau and Spencer Brody},
Title = {{XCVB}: Improving Modularity for {C}ommon {L}isp},
Booktitle={International Lisp Conference},
URL="http://common-lisp.net/projects/xcvb/",
Year = {2009}
}
@InProceedings{XCVB,
author = {Fran\c{c}ois-Ren\'{e} Rideau and Spencer Brody},
title = {{XCVB}: an {eXtensible} {Component} {Verifier} and {Builder}
......@@ -172,7 +165,7 @@ Article{XCVB,
number = {4},
year = {1979},
pages = {255-65},
bibsource = {DBLP, http://dblp.uni-trier.de}
bibsource = {DBLP, http://dblp.uni-trier.de/}
}
@Article{Sidebotham98,
......@@ -186,6 +179,5 @@ Article{XCVB,
@Misc{scons,
key = {SCons},
title = {SCons website},
url = {www.scons.org}}
url = {http://www.scons.org/}
}
......@@ -64,7 +64,7 @@ such as distributing software, managing bugs, connecting people,
solving dependency versioning issues (aka ``DLL hell''), etc.
\subsection{Analogy with \texttt{make}} % {\make} looks weird here
\subsection{Analogy with {\large \make}}
\label{sec:analogy-with-make}
It is conventional to explain {\ASDF} as the {\CL} analog of {\make}~\cite{Feldman79}:
......@@ -148,7 +148,6 @@ as it traverses its dependency tree~\cite{AITR-874}.
We will discuss this further in Section~\ref{sec:plan-generation},
\subsection{Basic {\ASDF} object model}
\label{sec:asdf-object-model}
......@@ -209,7 +208,7 @@ This is done by the generic function \lisp{find-system}, which searches
for the system definition in a configurable system registry
(and its in-memory cache).
The system definition search is one of the aspects of {\ASDFi} that we reformed;
the previous protocol had to be initialized using arbitrary lisp code,
the previous protocol had to be initialized using arbitrary Lisp code,
and had a number of undesirable features.
See Section \ref{sec:input-locations}.
{\operate} then generates a \emph{plan} for completing the {\operation}
......@@ -346,12 +345,12 @@ We discuss this further in Section \ref{sec:future-directions}.
\rtof{
I don't believe that's correct. The rules in the makefile are not the
plan --- they are the pieces out of which a plan is assembled (if \make{}
plan --- they are the pieces out of which a plan is assembled (if {\make}
plans; I am not convinced this is the case). The parallel is the system definition in
\ASDF{}. That is not a plan; that is what the plan is assembled out of. For
example, if I ask \ASDF{} to do a load-op on a system, it will first build a
{\ASDF}. That is not a plan; that is what the plan is assembled out of. For
example, if I ask {\ASDF} to do a load-op on a system, it will first build a
plan, an ordered sequence of operation - component pairs. \emph{Then} it will
execute that plan. I don't believe that \make{} does anything like this. In
execute that plan. I don't believe that {\make} does anything like this. In
fact, I don't understand how make actually does its job. Similarly, I can
have a bunch of rules about how to build the pdf of the ASDF doc from texinfo, but those
rules will not be part of the plan if I ask make to build the html version of
......
......@@ -20,7 +20,7 @@
% }
% \draft{Symbolics \defsys{} here... Kantrowitz claims that it is a
% \draft{Symbolics {\defsys} here... Kantrowitz claims that it is a
% \emph{procedural}, rather than a structural system definition tool. Cites the
% BUILD system~\cite{AITR-874} as a structural tool.}
......@@ -30,7 +30,7 @@
% \begin{itemize}
% \item More declarative than other systems;
% \item Declarative specification of transformations between \emph{grains} (not
% offered by various flavors of \defsys{}.
% offered by various flavors of {\defsys}.
% \item Clear treatment of distinction between macro dependencies (compile-time)
% and call dependencies (run-time --- load time in our jargon).
% \item Dependencies are described directly, rather than in terms of system
......@@ -43,41 +43,41 @@
% \end{itemize}
% }
A key inspiration for ASDF was \mkdefsys{}, Mark Kan\-tro\-witz's portable
\defsys{} facility~\cite{kantrowitz:91}. At the time when \mkdefsys{}
A key inspiration for ASDF was {\mkdefsys}, Mark Kan\-tro\-witz's portable
{\defsys} facility~\cite{kantrowitz:91}. At the time when {\mkdefsys}
was developed, there was no portable, non-proprietary system definition
facility for {\CL}, as Lisp moved off special-purpose platforms and onto
general-purpose hardware. Prior to this (and substantially prior to a true
\emph{Common} Lisp), there were a number of different system-defining
facilities, notably the Symbolics \defsys{}~\cite{CHINE-NUAL}\footnote{Cited by Robbins~\cite{AITR-874}}, but people wanting to
facilities, notably the Symbolics {\defsys}~\cite{CHINE-NUAL}\footnote{Cited by Robbins~\cite{AITR-874}}, but people wanting to
portably define systems had to rely on \lisp{LOAD} scripts and/or
\lisp{REQUIRE}.
The \ASDF{} manual~\cite{ASDF-Manual}, discussing \mkdefsys{} as an inspiration,
explains that it was intended to better use \CL{} features (notably CLOS) for
extensibility. \mkdefsys{} is written in pre-CLOS \CL{}. However, we argue
that a primary reason for \ASDF{}'s success was not its CLOS architecture, but
The {\ASDF} manual~\cite{ASDF-Manual}, discussing {\mkdefsys} as an inspiration,
explains that it was intended to better use {\CL} features (notably CLOS) for
extensibility. {\mkdefsys} is written in pre-CLOS {\CL}. However, we argue
that a primary reason for {\ASDF}'s success was not its CLOS architecture, but
its elegant use of \lisp{*load-truename*} to solve the social problem of
installing and referencing lisp libraries. The problem of \emph{installing}
lisp libraries was not helped by \mkdefsys{}, but was substantially eased by \ASDF{}.
installing and referencing Lisp libraries. The problem of \emph{installing}
lisp libraries was not helped by {\mkdefsys}, but was substantially eased by {\ASDF}.
See
Section~\ref{sec:input-locations} for more discussion of this issue.
BUILD~\cite{AITR-874} was a substantially earlier Lisp build system (antedating
\CL{}), and an inspiration behind \mkdefsys{}.
BUILD attempted to be more declarative than \make{} and other predecessors. It
{\CL}), and an inspiration behind {\mkdefsys}.
BUILD attempted to be more declarative than {\make} and other predecessors. It
\emph{may} have introduced the notion of creating a complete operation plan
before executing any operations; we are not certain.
% \draft{Too-specific notes on \mkdefsys{} that need to be winnowed for the
% \draft{Too-specific notes on {\mkdefsys} that need to be winnowed for the
% paper....
% Some key ideas present in \mkdefsys{}:
% Some key ideas present in {\mkdefsys}:
% \begin{itemize}
% \item parametric \texttt{operate-on-system} function.
% \item selective recompilation to minimize work
% \item declarative system spec --- specify dependencies and components;
% \mkdefsys{} infers the procedure.
% {\mkdefsys} infers the procedure.
% \item intended to be extensible
% \item Use of Unix pathnames as de facto standard --- portability across unix
% and mac was punted to logical pathnames.
......@@ -87,7 +87,7 @@ before executing any operations; we are not certain.
% \emph{Not} present:
% \begin{itemize}
% \item Clever use of \texttt{*load-truename*} to locate source files. The
% problem of \emph{installing} systems was not helped by \mkdefsys{}. At the
% problem of \emph{installing} systems was not helped by {\mkdefsys}. At the
% top, \texttt{:SYSTEM}s had to have absolute pathnames.
% \item Automatic placement of binary files. I believe this had to be handled
% through use of conditional compilation (reader macros) combinated with
......@@ -103,7 +103,7 @@ before executing any operations; we are not certain.
% Features not taken over into ASDF:
% \begin{itemize}
% \item \mkdefsys{} had \texttt{:PRIVATE-FILE} as a component type that
% \item {\mkdefsys} had \texttt{:PRIVATE-FILE} as a component type that
% could be used for, e.g., user-specific configuration files.
% \item You can do package-wrangling in the system definition, instead of coding
% package into files.
......
This diff is collapsed.
\section{Dynamic Code Upgrade}
\section{Dynamic Code Update}
\label{sec:upgradeability}
......@@ -71,12 +71,13 @@ We believe that this there are a number of reasons for this design decision:
{\ASDF} supports such a use pattern.
\end{itemize}
The Ytools ``chunk manager'' (see Section \ref{sec:related-works})
takes the {\ASDF} approach to an extreme,
maintaining code units smaller than file-size
to maintain the integrity of long-lived {\CL} images.
On the other hand, XCVB (Section \ref{sec:XCVB}) takes a different perspective,
attempting to isolate system maintenance tasks in separate processes.
% \ftor{I don't think this is relevant here, only a distraction.}
%The Ytools ``chunk manager'' (see Section \ref{sec:related-works})
%takes the {\ASDF} approach to an extreme,
%maintaining code units smaller than file-size
%to maintain the integrity of long-lived {\CL} images.
%On the other hand, XCVB (Section \ref{sec:XCVB}) takes a different perspective,
%attempting to isolate system maintenance tasks in separate processes.
Because {\ASDF} performs its build tasks in the user's current Lisp process,
upgrading {\ASDF} entails modifying some existing
......@@ -131,7 +132,7 @@ as long as it behaves in a semantically equivalent way.\footnote{
For instance, assuming functions are seldom rebound,
dynamic calls may be implemented just like static calls,
except that the value of the binding is a cache that gets invalidated
between the time the function is rebound and the cache is used.
between the time the function is rebound and the time the cache is used.
As for static calls, they may be implemented
not just by linking a call to the proper code value,
......@@ -141,10 +142,10 @@ as long as it behaves in a semantically equivalent way.\footnote{
that will never be rebound.
}
The two difficulties named above are inherent in redefining functions
The two above difficulties are inherent in redefining functions
and are not specific to either {\CL} or {\ASDF}.
However, these difficulties are particularly relevant in the case of {\ASDF}
which drives compilation and loading of Lisp code
However, these difficulties are particularly relevant in the case of {\ASDF},
that drives compilation and loading of Lisp code
possibly including new versions of {\ASDF} itself.
{\ASDF}'s code is therefore likely to be in the continuation
of its own function redefinitions,
......
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