file access FAQ

[David Kieras <kieras@engin.umich.edu>]

This should be an FAQ:  What's a good way to access files in
different directories in MCL, in a way that will not require code
changes to run in other CL implementations or on other  Macs, and
allows some independence of the directory hierarchy?   

That is, my code consists of many projects, which I like to keep
in their own folders and sub-folders, but which share code which
I want to have only a single copy of, and which exists at more
than one level.  Some of the shared code is used by two or more
different families of projects, and each family shares code
internally as well. The loading for a project is done by a set of
loads in a file for each project.   So when I load up a project,
I need to load code not just from the local directory, but from
all over the place.  

Furthermore, I move the code between different Macs, and would
like to be able to move it to different CL implementations and
platforms, with no changes in the loading code.

On my Apollos, this is easy: the loads describe a file whose path
was of the form "link-name/file-name" and then with the shell I
would just define links to point to whatever directories the
files were in on that machine (even to a different machine on the
network) and so the lisp code didn't have to be changed to
reflect the file structure of the machine, or even which lisp
implementation on which kind of unix machine it was on.   

It isn't intuitively obvious how to do this in MCL in a way that
will allow the code to similarly load correctly without being
changed across machines or platforms. So the solution has to be
pure CL, but using aliases to mimic links would be fine too. 

E.g. the ugly thing I am doing now is to spell out the complete
path in the loads, and then when I move the code to another Mac
or machine, I alter the paths in the code with a global
substitution;  I constrain the Macs to have isomorphic file
structures, so only the name of the disk drive has to be changed.
Expedient, but ugly, and a constant nuisance.

A better approach would be appreciated!