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

[mike%acorn@LIVE-OAK.LCS.MIT.EDU]

        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.

I concur that they're ok, and even necessary for a symbolic language.
The problem I feel is that they are good for preventing "symbol"
mixups, but not "modularization".  E.G., suppose you have a symbolic
differentiator, and so do I, and we don't want my dx/ds symbol to be
confused with your dx/ds symbol lest they not be able to work
together on an expression being differentiated.

Unfortunately, what packages are mostly used for is for some notion
of "modules" or "subsystems". (I agree that in lisp systems which
cons up expressions and eval or compile them that there is little
difference between these two scenarios, and we have to allow for
them, but most systems just don't do that kind of thing.)  This is
why I think the notion of LOCALE's from scheme or T or whatever keeps
cropping up. My belief is that all "environment" (as opposed to
package or "obarray") based approaches to solving name conflict
problems are really designed to solve the problems of "modules" or
"subsystems" for software engineering. This is a different problem
 from what packages can really solve.

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

The last thing I saw on the subject which was under consideration by
the x3j13 compiler committee was a proposal to treat the "seven"
specially as a compiled file header. This is more than just
implicitly evaling them at compile time. Basically, this would clean up
the issue of what "side effects" these have at compile time vs.
load time of the compiled file. It would also bless specifically the 
notion of a file-format for common lisp programs, thereby 
making it clearly a lose to put IN-PACKAGE calls in the middle
of files, etc. This has not been firmed up yet.

What I think is needed is really a STYLE GUIDE to common lisp.
Something that says how you OUGHT to program to avoid the majority
of problems with things like the package system, etc. I think most
package problems come from misuse.

For instance, I would recommend that people be encouraged to 
avoid USE-PACKAGE other than for package LISP, and instead 
enumerate symbols one by one using the other package functions.
My experience is that noone wants to qualify any names so what
they do is carefully use every package that they've ever seen,
not realizing that 

(let ((string "abcd"))
  ....)

in their code is creating a spec-bind because they are using a package
where string is a special.

nuff said.

...mike beckerle