Hi, Neil Jerram <[email protected]> writes:
> Are there deeper problems with compilation and define-class / > module-define? E.g. is it possible that correct compilation of code > following a define-class or module-define would be dependent on > understanding the define-class/module-define properly? No. For any variable that’s not lexically bound, the compiler generates instructions that amount to ‘(module-ref (current-module) VAR)’. Note that the warning reports /possibly/ unbound variables. Variables that get bound at run-time via ‘module-define!’ or similar are ignored, and that’s precisely what ‘define-class’ does. > On a loosely related point, I notice that we have deprecated eval-case > in 1.9.x, in favour of eval-when. But 1.8.x only has eval-case; so > isn't the deprecation going to make it more difficult to handle code > that has to be different in 1.8.x and 1.9/2.0? Yes, I agree it’s problematic. What about leaving both forms for 2.0, and only deprecating ‘eval-case’ in the next stable series? > Alternatively, should we add a suitable eval-when to the next 1.8.x > release, to help with this? That wouldn’t help much since it wouldn’t work with < 1.8.8. Thanks, Ludo’.
