eval'd macros (the other point of view)

["Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>]

      (defun fn () (mac))
      FN
      (compile 'fn)
      The following functions were referenced but don't seem defined:
      MAC referenced by FN
    FN

    I also consider this to be a bad idea.  Does this mean that COMPILE-FILE
    will also do this?  If so, then it will generate warnings on correct code.
    In fact, since there is no forward declaration facility, some code (mutually
    recursive fuctions) would necessarily generate warnings on correct code.
    Alternately, are you suggesting that COMPILE should generate different
    warnings than COMPILE-FILE?  In this case, while you are not strictly changing
    the semantics of correct code (since it is a warning instead of an error),
    you are violating the intent of the consistency argument.

It is not incorrect to generate warnings on correct code.  A warning
says that the compiler cannot prove that some code is incorrect, but
that it has spotted something that may be an error, gross inefficiency,
or something else the user might want to look at.  Such warnings have
saved me hundreds of hours of debugging time, and I wouldn't want to do
without them.  If you don't like them, most compilers let you turn them
off.

Yes, such warnings do tend to spook naive users who are compiling other
people's code.  To suppress such warnings, Common Lisp does provide a
forward-declaration facility for functions: (declare (ftype...)) or
(declare (function ...)).  I don't think that the Spice Lisp compiler
uses these declarations to suppress warnings, but it should.

In most implementations that I have seen, Compile-File lists at the end
of the file, as a sort of warning, any functions that were used but that
are not known to the compiler.  A function generally becomes known
either by being present in the Lisp doing the compiling, by being
defined in a previously-compiled file, or by being defined somewhere in
the current file.  Dumping this list is done at the end of a file just
so that the order of definitions within a file doesn't cause a lot of
spurious warnigns to appear.  Co-recursive functions can be defined with
no problem, etc.

I don't much care whether Compile warns me about undefined functions or
not.  Since Compile-File waits till the end of the file to complain
about unknown functions and special variables, it seems consistent to
keep quiet about this when compiling functions one-by-one.

-- Scott