🚀 go-pugleaf

Joe Konstan (konstan@cs.berkeley.edu) writes:

  Certain things need to be loaded before others can be loaded
  or compiled.

  One solution is to use some version of defsystem and to
  carefully assure that the dependencies can be met on a
  per-file basis (i.e., no circular dependencies between files).

  A second alternative (which I've been using) is to create a 
  "header" file with all of the needed declarations and
  definitions.  This includes "empty" defclasses (no contents, 
  just the class name and superclass names), macro definitions,
  and some defgenerics and proclamations.  

I agree with Jeff Dalton's comments, especially the observation that
the C world essentially uses a DEFSYSTEM facility.  Here are some of
my own comments.

Many of the systems I've developed use macros or DEFVARs that require
other macros, or even classes and methods, to be loaded before they
can be compiled or loaded.  For example, a computed macro expansion
may contain an embedded constant CLOS instance.  This would seem to
require interleaving your header files with non-headers.  Also, some
meta-object programming might require the full class definition, not a
stub, to be loaded when a referring method is compiled or loaded.

An implicit assumption in your second alternative is the existence of
a load file or load function, which refers to all the files.  I find
it MORE modular, maintainable and declarative to use a DEFSYSTEM
facility.  Otherwise you must maintain separate functions for each
operation (load, compile, dump-to-tape, and so on), with many of the
same dependencies duplicated in those functions.  These functions
become one more piece of code you must worry about maintaining, with
the added complication that not one, not two, but, by definition,
EVERY person working on the system has reason to make changes.  This
is true for a DEFSYSTEM declaration as well, but I find the latter
much more maintainable in a multi-person project.

Also, a DEFSYSTEM lets you declare local dependencies, rather than
requiring the computational closure of all dependencies.  For example,
compiling "GAMMA.LISP" directly requires loading "BETA.LISP", but
loading "BETA.LISP" requires loading "ALPHA.LISP".  Thus, compiling
"GAMMA.LISP" requires loading "ALPHA.LISP".  The system we're working
on now comprises over 500 files.  We'd rather not figure this stuff
out for each of them.

A DEFSYSTEM also (presumably) lets you define modules, subsystems and
utility systems, allowing you to modularize dependency declarations
appropriately.  This in turn makes it easier to have several different
versions of a system, each of which may load some files that others do
not.

John Burger
john@mitre.org