Re: eval'd macros (the other point of view)

[hpfclp!diamant@hplabs.ARPA]

   From: David C. Plummer <hplabs!DCP@SCRC-QUABBIN.ARPA>
   Subject: eval'd macros

    Date: Mon, 3 Feb 1986  20:36 EST
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>


	(defun fn () (mac))            ;==> FN
	(defmacro mac () `'foo)        ;==> MAC
	(fn)                           ;==> ***Error***
    ...

    In my
    opinion, this should work without an error in the interpreter.  Hacking
    in the interpreter would be fairly awkward if it didn't.  However, the
    fourth paragraph on page 143 seems to give implementors permission to do
    compiler-like macro expansion when a defun is first seen.  I wouldn't
    want to use such an implementation, but it probably is legal as the
    manual currently stands.

I would like to second Kent Pitman's opinion.  Maybe no one has mentioned
this objection because it is so obvious -- it is still very important.
I think that it is a bad idea to have the interpreter defer expansion of
macros because it is just one more case of differing interpreter and
compiler semantics.  If I am to believe the statement regarding consistency
in the introduction of CLtL: "The definition of COMMON LISP avoids such
anomalies by explicitly requiring the interpreter and compiler to impose
identical semantics on correct programs so far as possible," then as Kent
suggests, the interpreter should not defer expansion because the compiler
is required not to.

  If the system goes further and actually DOES compile
  the defun, then I would consider it a user-interface bug that the
  compiler doesn't tell the user that it couldn't find a function call
  MAC.

  (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.

The problems with compiler/interpreter semantics are bad enough in packages
that we should try to avoid unnecessarily propagating them in other areas.

John Diamant
Fort Collins Systems Division	UUCP:  {ihnp4,hplabs}!hpfcla!diamant
Hewlett Packard Co.		ARPA/CSNET: diamant%hpfcla@hplabs
Fort Collins, CO