Harald van Dijk <[email protected]> writes: > Using a test rep file test.jl: > > (define-structure test > (export test-var) > (open rep) > (defvar test-var nil) > (eval-when-compile (setq test-var t))) > > a second test file test2.jl: > > (require 'test) > (setq test-var t)
Sure enough. It seems that eval-when-compile is more persnickety about assigning values to void variables. In fact, if you use sawfish rather than rep to compile the file you get the same error you saw when compiling sawfish (void-variable, rather than unbound variable). The compiler will normally just issue a warning if you setq a void variable, but if you do it inside an eval-when-compile it generates an error. Unfortunately, we still need the eval-when-compile bit to suppress compiler warnings: when the variables are called as functions by the prompt code they're called with arguments and the compiler thinks they should have only one. I'm a bit uncomfortable including the prompt module from itself; it seems to compile and work, but I'm not certain what, if any, difference it might make. Perhaps someone who knows rep better than I do can tell me I'm worrying about nothing? I haven't been able to come up with another solution, though. If I include defvar statements in the eval-when-compile clause the original compiler warnings show up again. If it's a choice between removing the eval-when-compile clause entirely and including prompt from itself, I lean toward the former since we know what's causing the warnings and that they're spurious. -- Jeremy Hankins <[email protected]>
