Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!ncar!husc6!mit-eddie!apollo!weissman
From: weissman@apollo.COM (Mark Weissman)
Newsgroups: comp.lang.lisp
Subject: Unix Lisp Environments (Distributed Builds)
Message-ID: <43248759.12972@apollo.COM>
Date: 10 May 89 18:52:00 GMT
Organization: Apollo Computer, Chelmsford, Mass.
Lines: 35


Distributed Builds of large lisp systems:

> Macros/inline functions referenced in an expression get
> whatever version which is currently in your world.  
> If you didn't load the macro def, the compiler assumes it is a
> function (and may or may not complain about it later).

This system loads the minimal subset (user specified) necessary to
compile a file into an initially virgin lisp world.  If the required
files are compiled the binaries are loaded, otherwise the sources.  I
beleive that it is the case that a given file will usually only
require a handful of others for compilation to proceed.  With Lucid,
it is much faster to load an interpretted file than to compile and
load a file.  

These mini-builds can then be distributed over a network.  The
overhead cost of starting up a new lisp world is minimized by having
each world remain resident and reusable throughout the course of each
build.  Required files present in each world do not need to be
reloaded when compiling subsequent files.

> - Lisp development typically does not require the same
>   edit-compile-link cycle that other languages do.  A make-like facility
>   is not as important.

I disagree.  In a large lisp system when a widely used macro is
redefined many files may need to be compiled.  I have worked on
projects many entire days were spent recompiling a large system.  It
is true that for a small system with only one developer there is less
need for source control and make facilities.  Due to the fairly high
overhead involved with lisp applications, they tend to be large systems.

Mark Weissman
weissman@apollo.com