A proposal

[MURRAY%umass-cs.csnet@CSNET-RELAY.ARPA]

A major goal of Common-Lisp standardization is
to make it possible to be able to write a system, and
have that system run on any machine that runs common-lisp.

Given this goal, The language should provide an easy
way of packaging (no pun intended) up a system,
such that it can be
easily moved onto another machine.  The package system
provides a nice way to seperate out your system from
anything existing on a machine, but I think most people
would agree it is a pain when it comes
to development.  This is because a system of any size
is generally broken into many files, and while developing,
you don't necessarily load them all in, and in
the "proper" order, before working on the some part of
the system.  Now many might say that dealing with this is
an "enviornment issue", or sloppy programmer practice,
such that you or your machines software
should provide you with ways to deal with these problems.
While portability is the major concern, let us not forget that another
benefit of standardization is that programmers can
move to another project, company, or system and
not have to learn an vastly different enviornment.

Another problem that arises with multiple files, is compiling them,
such that some files needed to be loading before others, to get
macros and functions defined. 

It appears that common-lisp is more oriented to
dealing with single files, rather than a system with a group of them.  The
MODULES stuff is a pretty weak attempt, and seems more oriented
towards a user of systems, rather than the systems themselves.

Therefore, I think that we should seriously consider including something
like the DEFSYSTEM of Zetalisp.  Now, I think Zetalisp's defsystem, while
very powerful, it's fairly complicated, has horrible syntax, and isn't quite
the right thing.  It think the defsystem we want should include 
file interface information that is currently dispersed through all the
files of the system.

The proposal is to have something like defsystem that would define
the files, compile and load dependancies, 
packages to be created, the import and exporting of symbols within those
packages.  A file can indicate which part of the system it is.
Using the Defsystem information, the 
file itself wouldn't need to include it all.  Thus a file could have
something like:

(In-System "Robot" "Motor-Control")

Which would indicate that this is module Motor-Control of the Robot system.
Using the system information, your would know which package the file should
be in.  If the system information wasn't loaded, it would load it in, creating
the package with all it's importing, exporting, shawdowing, etc.  If files
needed to be loaded before this one,  it could either load them in, or
maybe ask you if you want it to, or at least Warn you that they haven't 
been loaded.  This way, while developing you wouldn't lose.
This avoids having to have all that information redundantly specified
in all the files.  Most programmer do all of this by hand, so why not
let the system doit.  A software system could also provide other
"Enviornment" tools, like letting you know what needs to be recompiled,
making it easy to add imports and exports of symbols, nice display
of file/module dependancies, etc.  

As far as compiling, again the system information could be consulted on
an individual file basis.  As with Zetalisp defsystem, you only need
to say something like (MAKE-SYSTEM "ROBOT" :COMPILE) to have it do
all the files, with all their dependancies.   When you went to move
the system to another machine, all the information would be
in the defsystem, so if you need to change the name of packages, you
would only need to do it there.  It would also be a good place
to put #+ReadTime conditionals, so you would only include files/modules
for particular software systems.

I may be wrong, but it seems most groups doing development
have something similiar that they use already.  

I would be more than willing to write up a concrete proposal, and code
up a portable version of it for testing, if the community is
going to take it seriously.  

Kelly Murray
University of Massachusetts