Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!agate!eos!ptolemy!raymond
From: raymond@ptolemy.arc.nasa.gov (Eric A. Raymond)
Newsgroups: comp.lang.lisp
Subject: Re: Unix Lisp Environments (Why the slow evolution)
Message-ID: <1145@ptolemy.arc.nasa.gov>
Date: 9 May 89 19:46:43 GMT
References: <431e7355.12972@apollo.COM>
Reply-To: raymond@ptolemy.arc.nasa.gov.UUCP (Eric A. Raymond)
Organization: NASA Ames Research Center
Lines: 54

In article <431e7355.12972@apollo.COM> weissman@apollo.COM (Mark Weissman) writes:
>
>but just to disagree with the statement that its difficult to compile
>lisp files standalone:

I think the original poster was pointing out the standard macro/inline
function problem.  That is, expressions are compiled in the current
environment.  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).

A similiar situation occurs in the C world, where you have macros
(#defines), function prototypes, and variable definitions to consider
(the latter two cases are usually caught by a good compiler).  This is
a bit different in the st definitions are valid for only a single
source file.  Thus each file is resposible to include these
definitions.

The REQUIRE construct, if used religously, can provide similar
functionality in many cases.

Of course there are extra things that a DEFSYSTEM supplies ....

Summary: Lisp and C share similar problems.


>  distributed building of
>  large lisp applications across distributed networks on a per file
>  basis

This really doesn't make much sense. 

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

 - Since there is rarely the need to compile lots of code at one time,
   distribution of compilation (which I assume yields speedup) is not
   as great a win.  Exceptions to this may include building old
   versions of software, distributing customized code; these are
   typically infrequent operations, so speedup is not such a great
   win, again.

 - I assume that you must have n distinct lisp worlds on n machines.
   So how do you get around the problems I discussed above (the need
   to have proper environment loaded)?  In C you are forced to read in
   your #include files for each source file compiled.  In Lisp, you
   just load it into your world once.  If you have n Lisps, each much
   load the the environment in.

-- 
Eric A. Raymond  (raymond@ptolemy.arc.nasa.gov)
G7 C7 G7 G#7 G7 G+13 C7 GM7 Am7 Bm7 Bd7 Am7 C7 Do13 G7 C7 G7 D+13: Elmore James