[asdf-devel] proposal to split ASDF in half

Robert P. Goldman rpgoldman at sift.info
Thu Mar 13 14:42:01 UTC 2014

Daniel Herring wrote:
> Hi all,
> This has bugged me for years, and recent traffic brings it back to the
> forefront.  I apologize that this email is more a teaser than a complete
> solution, but that's what time allows for right now.
> In my opinion, a lot of the complexity in ASDF is caused by its
> conflation of two separate goals: a "build system" and a "loader".

IMO a lot of the confusion about ASDF is caused by not understanding
that systems like CL and Smalltalk don't actually have build systems or
loaders.  They have constraint systems that aim to preserve the
integrity of a running image over modifications to code.

I believe Faré and I discussed this issue in our first ASDF paper at
ILC.  For an even more radical proposal, see McDermott's earlier ILC
paper about his chunking mechanism, which allows programmers to specify
integrity constraints even for individual data structures.

Thinking about ASDF this way, instead of trying to fit it into the world
view of make, clarifies a lot of the sisues.

> If CL is to grow from a dev-centric ecosystem to have a large base of
> "normal users", I think we need to start finding ways to enable better
> long-term stability.  Pre-tested, "binary" releases are exactly what an
> end user wants.  Applications need to "just work" and not break whenever
> a dependency changes its API.

Normal users don't want to build or load their software at all, nor do
they want a CL environment.  They want to click on an icon and have a
program start and run.

ASDF does not have anything to say to normal users, any more than make,
ant, ocaml, or gcc does.

This is not an application area to which ASDF will aspire during my
tenure as maintainer.

The sole exception is that ASDF will continue to support *programmers*
(not users) who want to use ASDF to describe how to build standalone
executables for delivery.

ASDF is a programmer's tool.  Users will have to find someone else to
meet their needs.

My resources are stretched to the limit maintaining ASDF as the tool it
is today.


More information about the asdf-devel mailing list