So what do people want out of a module system or package system?
I'm a straightforward soul; if I can make a change in one
module and not have to recompile the entire system to make it
work, I'll be (reasonably) happy.
After that, you have a bunch of subtle issues... the more you
tell the compiler about a module, the more optimization it can
do. "This will never be called from outside this module" is an
invitation to inline something and throw away the function
definition, for example. "The only kind of number this will
ever be passed is an integer" is an invitation to optimize
away your typechecking and variant-case code.
Basically, the problem with separating things into packages
is that the compiler no longer has global knowledge during
compilation. When you compile a source file, it can't tell
how other modules will use it -- so it has to generate
very robust code that checks for and handles all the cases --
even the ones that are flatly impossible. So you get slower
machine code that takes up more space, or you wind up
burdening the programmer with keeping track of optimization
issues rather than just solving problems.
And then there are a bunch of namespace-collision issues.
CL "solves" them by having each package be a separate
namespace, but I've always hated that solution myself; I
like being able to ask what <symbol> is bound to and get
an unequivocal answer for any single environment.
One thing that might work better, would be to have a lexical
scoping structure of some kind, such that the local names
don't get bound outside the scope of the module. In schemes
that allow nested function declarations, I often control
namespace by defining functions that can only be called from
within another function, within the lexical scope of that
function. If nested function definitions are *Required*
by the language, they are an excellent way to control
namespace and provide optimization information naturally in
a way that simply reflects the structure of the code.
Bear
|