[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


Consider the following piece of code:

    (in-package 'me)
    (require 'foo)    ; Module FOO creates package FOO

There is nothing wrong with this when you run it through the interpreter,
but it dies when you try to compile it.  Why?  Because the call to REQUIRE
doesn't get evaluated at compile time, thus module FOO doesn't get loaded,
package FOO isn't created and SOME-FUNCTION isn't made an external symbol.
The manual has taken some pains to describe how you should order the calls
to set up the package environment and load various modules at the beginning
of each file, but it doesn't seem to interact with the compiler very well.

Making REQUIRE so it is always implicitly (eval-when (eval compile load)...)
would solve the problem, but this would create problems, too.  I have at
least one utility where I want one module loaded at compile time to provide
definitions for some rather hairy macros, and another (much smaller) module
around at load time which contains a few functions for runtime support.

I'm inclined to think that this is another manifestation of fundamental
defects in the package system, combined with general vagueness on what
kind of processing goes on at compile time.  Unfortunately, I don't really
have any good solutions for either problem.  It seems like what we really
need is some mechanism to declare that REQUIRE and various other defining
forms (like DEFSTRUCT, DEFTYPE, DEFMACRO, etc.) should be evaluated at
compile time, *unless* you specify otherwise.  Or, maybe a "defenvironment"
construct to take the place of random function calls to set up the package
system and miscellaneous environment.

-Sandra Loosemore