Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!sun-barr!cs.utexas.edu!uunet!mcvax!ukc!etive!aiai!jeff
From: jeff@aiai.ed.ac.uk (Jeff Dalton)
Newsgroups: comp.lang.lisp
Subject: Re: Unix Lisp Environments (why the slow evolution)
Message-ID: <418@skye.ed.ac.uk>
Date: 8 May 89 17:03:36 GMT
References: <7802@zodiac.UUCP> <ROBERTS.89May4173615@studguppy.lanl.gov> <30132@apple.Apple.COM>
Reply-To: jeff@aiai.UUCP (Jeff Dalton)
Organization: AIAI, University of Edinburgh, Scotland
Lines: 47

In article <30132@apple.Apple.COM> malcolm@Apple.COM (Malcolm Slaney) writes:
   As far as the original question goes...it is much harder to build a
   good system building tool for Lisp then it is for a conventional
   language like C/Fortran/whatever.  In most conventional languages each
   compile can take place independently since the compiler doesn't depend
   on the environment.  This is not true of Lisp.

   What I really missed on the Symbolics machine was a good source code
   control system (no file versions are a bad way of doing that).  I
   ended up keeping my Lisp sources on a Sun, accessed them on the LispM
   with NFS and used RCS on the Sun.

I think you are right that it is hard to build good tools for Lisp.
Another problem is that Lisp gets certain parts of the programming
environment, such as TRACE, more or less for free.  Since the free
tools are pretty useful, there's less pressure to develop better tools
than there might be otherwise.

I also agree that Unix tools can be used effectively with Lisp.
Indeed, it is possible to use Lisp in a way that allows compilations
to be more or less independent.  Such techniques are often used with
Lisps, such as KCL and Franz, that are packaged so that file
compilation can be invoked by a typing a command to the shell.

In C, files are not completely independent, but it is (fortunately)
possible to put the necessary information about files not currently
being compiled into ".h" files for #include.  Some Lisps (such as
Franz) have an include, but usually a file has to be loaded.  So,
where in C you'd write

     #include macros.h

in Common Lisp you have to write something like this:

     (eval-when (eval compile)
       (load "macros"))

If you start a fresh Lisp for each file compilation, and if each file
loads in the extra information it needs to be compiled, the situation
for Lisp becomes very similar to that for C.  Moreover, you can use
makefiles, just as you would for C, and other Unix tools such as RCS.
And if A.lisp needs to be compiled before you can compile B.lisp, you
just put something like

     B.o: A.o

in the makefile.