{Improved version} EXPORT-IMPORT and the other random commands

["Robert W. Kerns" <RWK@ai.ai.mit.edu>]

    Date: Sun, 07 Feb 88 00:15:12 PST
    From: hilfingr%tully.Berkeley.EDU at berkeley.edu (Paul Hilfinger)

    I'm also interested in seeing the "package problem" cleared up.  I
    have two questions.

    1) Has anyone written a definitive "why CL packages stink" article 
       or message, preferably one that someone regards as definitive?
I don't think there's complete agreement on all the
reasons why "CL packages stink".  Personally, in fact,
I think they're not bad, in use, but the setup is what
stinks.  Others would disagree.

But I think there's pretty good agreement that the
seven extremely perverse functions are perverse.

    2) You write

           > ... The underlying idea that you define the package environment
           > by performing a series of side-effects on the package system
           > is so wrong it is beyond repair.  It is so entirely sensitive
           > to complex and obscure order-of-events issues that even if
           > you were successful in getting all implementations to do
           > exactly the same thing, real-life users could not adaquately
           > standardize their workstyles and interactions to avoid
           > problems, even if they could understand all the rules!
           > 
           > I think the time would be better spent on specifying and
           > adopting a DEFPACKAGE macro.  This would always be the first
           > form of the first file loaded.  (Or at least, before any
           > IN-PACKAGE's for that package)....

       Are you saying that this DEFPACKAGE macro would NOT have any side-effects
       on the package system?  How would it have its effect?  Or, more
       generally, what is the underlying idea with which you want to
       replace "side-effects on the package system"?  
No, the important word up there was "series".  There's no
problem with a single declarative form, at the very start.
It's when you dribble things out over several files with
a series of "functions" which have to be treated specially
by the compiler, that you start running into problems.
Not to mention the confusion factor.  The very fact that this
silly mnemonic (which I can never remember) is needed to
keep the order straight should be a dead givaway that something
is wrong with splitting up declaring the package into a series
of micro-steps.  You might think of these as "package microcode".
It shouldn't be supprising that there are dependencies on the
particular way an implementation does its environment.

If you declare imports, exports, inheritences, etc. at the
same time you CREATE the package, you can't have any problems
with symbols accidentally getting created before things are
set up right.  (Just for one example).
						      (Somehow, electronic
       mail adds an unwonted note of harshness to my syntax; that last
       question was meant to be straight, not rhetorical.)

I know the problem.  You'll notice I sent an improved version of
my note, when I noticed it sounded like I was being critical of
Bob Boyer's complaint.  (Instead of urging a different approach to
solving it).

    Paul Hilfinger
    U. C. Berkeley
    Hilfinger@Berkeley.EDU