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

Full draft of related work section (except ytools still missing).

parent a8dc3cb6
% \section{History}
% \label{sec:history}
\begin{itemize}
\item LOAD scripts
\item Deep background --- Symbolics, etc. defsystems?
\item MK-DEFSYSTEM
\item ASDF Classic --- Can we interview Dan Barlow for information?
\item Mudballs (did this ever go anywhere?)
\item XCVB
\item ASDF2
\begin{itemize}
\item Gary King for maintenance efforts before {\fare} took over.
\item {\fare} era
\end{itemize}
\end{itemize}
% \begin{itemize}
% \item LOAD scripts
% \item Deep background --- Symbolics, etc. defsystems?
% \item MK-DEFSYSTEM
% \item ASDF Classic --- Can we interview Dan Barlow for information?
% \item Mudballs (did this ever go anywhere?)
% \item XCVB
% \item ASDF2
% \begin{itemize}
% \item Gary King for maintenance efforts before {\fare} took over.
% \item {\fare} era
% \end{itemize}
% \end{itemize}
\draft{
Anything missing in the above?
}
% \draft{
% Anything missing in the above?
% }
\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.}
% \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.}
\draft{Notes on Symbolics defsystem taken from BUILD AITR unless explicitly noticed otherwise.}
% \draft{Notes on Symbolics defsystem taken from BUILD AITR unless explicitly noticed otherwise.}
\draft{Notes on BUILD:
\begin{itemize}
\item More declarative than other systems;
\item Declarative specification of transformations between \emph{grains} (not
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
operations. So don't say ``must build this when the other changes,''
instead say ``this module \texttt{macro-calls} these other modules,'' etc.
Necessary system operations are inferred from this information. This
information is called the ``reference level model'' and the ``task level
model'' is derived from it.
\item BUILD is also a plan-then-execute model.
\end{itemize}
}
% \draft{Notes on BUILD:
% \begin{itemize}
% \item More declarative than other systems;
% \item Declarative specification of transformations between \emph{grains} (not
% 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
% operations. So don't say ``must build this when the other changes,''
% instead say ``this module \texttt{macro-calls} these other modules,'' etc.
% Necessary system operations are inferred from this information. This
% information is called the ``reference level model'' and the ``task level
% model'' is derived from it.
% \item BUILD is also a plan-then-execute model.
% \end{itemize}
% }
A key inspiration for ASDF was \mkdefsys{}, Mark Kantrowitz's portable
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 Common Lisp, as Lisp moved off special-purpose platforms and onto
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{}, but people wanting to
portably define systems had to rely on \texttt{LOAD} scripts and/or
\texttt{REQUIRE}.
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}.
\draft{Too-specific notes on \mkdefsys{} that need to be winnowed for the
paper....
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{}.
See
Section~\ref{sec:input-locations} for more discussion of this issue.
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.
\item intended to be extensible
\item Use of Unix pathnames as de facto standard --- portability across unix
and mac was punted to logical pathnames.
\item Plan-then-execute. DAG is topologically sorted before anything is done.
\item Manages non-lisp components.
\end{itemize}
\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
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
telling the system about the binary output names different implementations
assumed. The problem was recognized though. However, on the owner's site,
this problem was handled by the Andrew File System, and something like
ASDF-BINARY-LOCATIONS was supported by allowing users to emulate this
feature of AFS.
\item Use of CLOS. Some of the things done by CLOS method combination in ASDF
are done by special keywords like \texttt{:FINALLY-DO}.
\item System versioning. Version-matching.
\end{itemize}
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
\emph{may} have introduced the notion of creating a complete operation plan
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
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.
\item \texttt{:LOAD-ONLY} components.
\end{itemize}
% \draft{Too-specific notes on \mkdefsys{} that need to be winnowed for the
% paper....
% 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.
% \item intended to be extensible
% \item Use of Unix pathnames as de facto standard --- portability across unix
% and mac was punted to logical pathnames.
% \item Plan-then-execute. DAG is topologically sorted before anything is done.
% \item Manages non-lisp components.
% \end{itemize}
% \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
% 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
% telling the system about the binary output names different implementations
% assumed. The problem was recognized though. However, on the owner's site,
% this problem was handled by the Andrew File System, and something like
% ASDF-BINARY-LOCATIONS was supported by allowing users to emulate this
% feature of AFS.
% \item Use of CLOS. Some of the things done by CLOS method combination in ASDF
% are done by special keywords like \texttt{:FINALLY-DO}.
% \item System versioning. Version-matching.
% \end{itemize}
% Features not taken over into ASDF:
% \begin{itemize}
% \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.
% \item \texttt{:LOAD-ONLY} components.
% \end{itemize}
}
% }
%%% Local Variables:
......
......@@ -1071,9 +1071,6 @@ Documentation is a pain, and is still a weakness of \ASDFii{}.
\subsection{History}
\label{sec:history}
\draft{One paragraph \textbf{only} to discuss the stuff in our history
appendix. Original fodder follows}
\input{history}
\subsection{Related work}
......
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