Re: Q on byte-compile problem

[Stuart D. Herring]

> 2. If I byte-compile `bar.el' in a session that has library `foo' loaded,
> then I get a warning that `bar' is not known to be defined (`bar' is used
> elsewhere in file `bar.el'). Is this normal? Shouldn't the compiler eval
> the
> (foo bar) and define `bar', so then (bar...) wouldn't be unrecognized? The
> (foo bar) occurs before the use of `bar' in `bar.el'.

The compiler macro-expanded the (foo bar) into something that presumably
began (defun bar ...) -- but it did not -evaluate- this.  When the
compiler encounters a normal `defun' at top level, it recognizes
thenceforth that the symbol named therein is a valid function.  But,
either because of the conditional nature of your (foo bar) or because of
its macro nature (someone who understands byte compilation better,
specify?), the compiler isn't aware that bar will (at load time!) actually
be defined as a function.

> I'm not too worried about the warnings, in any case, but it would be nice
> to
> eliminate them somehow - recommendations?

You could always put in an (eval-when-compile (unless (fboundp 'bar)
(defun bar ()))) to try to squelch the warning without doing any damage to
anything else.

> A. If I load `bar.elc' that was compiled via #1 (with `foo'):

Surely you mean without foo loaded for the compilation?

>  a2) in a session in which library `foo' was loaded - I get this error at
>      load time: "Symbol's value as variable is void: bar" [Bad].
>      Nevertheless, `bar.elc' seems to load OK, and `bar' is defined OK
>      (straight `defun' version).
>
> I want a2 to pick up the `foo'-defined version of `bar'. Obviously I'm not
> doing the right thing. However, I don't understand why loading `bar.elc'
> chokes in a2. I would expect the (when (fboundp 'foo)...) envelope to
> protect the call to macro `foo' during the load.

The byte-compiled file contains a call to the function `foo', which of
course involves evaluation of its argument bar.  The fact that the symbol
'foo now has a macro definition is irrelevant; the compiled code still
wants to call a function, and in fact dies before it even gets to the
point of discovering that (symbol-function 'foo) is now a macro.  The
result is that by the time the second form executes, `bar' is still
unfbound, so the defun runs.

> B. If I load `bar.elc' that was compiled via #2 (without `foo'):

Again -- you mean compiled with foo's macro definition available, yes?

>  b1) in a session in which library `foo' was not loaded - `bar's
>      definition is, as I expected, the straight `defun' version
>      (byte-compiled) [Good]

Here's the thing -- unless defining a function with the macro `foo'
involves the run-time use of other things from the foo library, why not
just have this case use the foo definition as well?  Part of the point of
byte-compiling is that macros can be expanded and then later used in an
Emacs which does not know about them.

Hope this helps,
Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.