Re: eval-when, eval-when-compile

SJT> A tarball containing the five files (including calc) that showed SJT> differences in .el, .elc pre-Martin-patch, and .elc post-Martin-patch SJT> forms is available at SJT> http://turnbull.sk.tsukuba.ac.jp/Tools/XEmacs/bytecomp-diffs.tar.gz mb> I've looked at these, and they show that unfortunately, this patch is mb> not yet ready for prime time. mb> I should have mentioned that you should have also diffed all the mb> byte-compiler warnings pre and post. They will show significant differences. mb> One problem is that mb> (eval-when-compile mb> (defvar foo)) mb> (defun bar () foo) mb> should not give a warning. It does. I've changed my mind. The above is a _user_ bug. It should simply be (defvar foo) (defun bar () foo) or (defun bar () (declare (special foo)) foo) And it's only a warning, so I don't mind. mb> I'm looking at the byte-code diffs - they seems to be harmless, mb> based on whether source or bytecode is inlined - only a very very mb> small possible performance difference. It looks like the gnus difference is irrelevant, calc just has a different timestamp, and my guess is that w3 is exhibiting similar behavior, although I can't tell for sure. Time to add Bill Perry to the CC list. Bill: We're planning to change the byte-compiler to have `eval-when-compile' no longer compile it's body - just eval it. w3 is the package most likely to be affected, both at the level of warnings and actual different generated code. But my guess is that it's safe. Martin