From: David Hanley
Subject: packages
Date: 
Message-ID: <360E6099.B94BFAAF@n.o.s.p.a.m.megsinet.net>
    I am working in a chess program in lisp for my own edification
and enjoyment.  It is playing ok, but the program keeps growing and
growing, and I have already had bugs due to duplication of functions/
variables across source files...

    I have been able to find very little information about packages, and

though it seems an ideal solution, there have been problems with them.
Specifically the compiler didn't like when package 'A referenced 'B
and 'B also referenced package 'A.  This is pretty much necessary for
my program to work efficently.

    Is there a good web tutorial for lisp book which covers packages in
detail?

dave
From: Kent M Pitman
Subject: Re: packages
Date: 
Message-ID: <sfw90j55fwf.fsf@world.std.com>
David Hanley <······@n.o.s.p.a.m.megsinet.net> writes:

>     I am working in a chess program in lisp for my own edification
> and enjoyment.  It is playing ok, but the program keeps growing and
> growing, and I have already had bugs due to duplication of functions/
> variables across source files...
> 
>     I have been able to find very little information about packages, and
> 
> though it seems an ideal solution, there have been problems with them.
> Specifically the compiler didn't like when package 'A referenced 'B
> and 'B also referenced package 'A.  This is pretty much necessary for
> my program to work efficently.
> 
>     Is there a good web tutorial for lisp book which covers packages in
> detail?

In most situations, accessing a package is separate from declaring it.
For example, if the implementation of package A has to reference B
but no exported references to B's symbols are also exported by A,
you won't find any problem as long as you pre-declare both packages.
I usually make a file called pkgdcl.lisp that contains all my package
declarations up front of a system that will need to cross-call.

If you find a situation where both package A and package B need to export
the same symbols, I recommend you make a separate package AB which 
is imported by both A and B and which exports the symbols both A and B
need to export.  If package A and B are separately maintained, then
make AB a third separately maintained system.

Usually you will find, I think, that the third package is not just a
kludge, but an improvement in modularity if you find a way to perceive
and name it correctly.  For example, if FROG:HOP and TOAD:HOP both
want to be the same symbol, then make a JUMP-PROTOCOL package that
exports HOP and then make both the FROG and TOAD package :USE
JUMP-PROTOCOL and :EXPORT some or all of the symbols from it.  If you
can't find a way to do it, consider that you might need four or vie
packages, not just 3, since your problem may be trying to shoehorn
things into the JUMP-PROTOCOL that belong in an independent module of
another kind.