Re: cc-vars.el

[Dave Love <d.love@dl.ac.uk>]

Martin Stjernholm <mast@lysator.liu.se> writes:

> So simple. ;) This is a good trick to know, but the same doesn't hold
> for variables.

I'm surprised it doesn't -- that's probably a minor omission -- but
you avoid warnings about unbound variables with `(eval-when-compile
(defvar fred))'.

> Of course, that's no proof that the symbol-value thing
> is (measurably) slower. I doubt it is.

Of course not since it generates identical code, but the fact that
it's optimized away means you don't suppress any warning.

> There are still warnings that aren't addressed by these tricks,
> though: The one about obsolete variables, and the one about incorrect
> number of arguments (which cc-bytecomp-defun doesn't solve either).

You can turn off such warnings in `byte-compile-warnings', but I think
it's best to get the warnings in a small amount of compatibility code.

> > I think CL used such a trick, but it's not (now) effective.
> 
> What is not effective about it?

It's optimized away.

> I've not investigated Gnus so I don't know either. Perhaps they use
> symbol-value and funcall everywhere.

No.  There are compatibility layers and (X)Emacs-specific files, and
it doesn't attempt to eliminate all warnings.

> Besides, cc-bytecomp also solves another matter, namely to make it
> compile cleanly even in the presence of an earlier version of CC
> Mode being loaded

I don't think it should worry about such things.  For builds of
packages, I maintain that compilation should be done file-by-file in
batch.  (If you're developing them and not restarting Emacs, you
probably want unload-feature to work properly with them.)