jts@cornell.UUCP (06/10/85)
From: jts (Jim Sasaki) > When is the proper time to signal the fact that FOO is an unbound function in > (FOO arg1 ... argN); when we capture the functional value of FOO, or when we > actually try to invoke that functional value? I prefer the latter, for two > reasons. First, we may never actually invoke the function, in which case > reporting it as unbound was not really necessary. Second, to report it > immediately would necessitate fatter compiled code .... While the laziness is > nice in compiled code, it is nice for the interpreter to catch it before > evaluating the args, for user-friendliness reasons. Given that Common Lisp is > committed to identical semantics in the interpreter and compiler, there are > three solutions: make compiled code a little fatter and slower, make the > interpreter less user-friendly, or allow a subtle difference ... between the > two processors to exist. Well, I think my priorities are first, identical semantics, then user friendliness, and finally the efficiency of compiled code. Or at least, if the semantics are not going to be identical, don't have subtle differences -- those are the ones that cause "bugs" that take forever to figure out. I don't think I believe the first of the two reasons (we may never actually invoke the function, in which case reporting it as unbound was not really necessary). Presumably, evaluation of one of the arguments failed, and that's why we didn't invoke the function? We can also argue that since the function value didn't exist, we were never going to invoke it, in which case there was never any need to bother evaluating the arguments. If the efficiency of the compiled code is that important, I'd vote for changing the interpreter to match. Jim Sasaki (jts@cornell, {decvax|ihnp4|uw-beaver|vax135|...}!cornell!jts)
barmar@mit-eddie.UUCP (Barry Margolin) (06/19/85)
The original posting asked for the appropriate time to report an
undefined function, before or after evaluating the arguments. I think
that it should signal the error before evaluating the arguments. This
is because the argument evaluation method can depend on the functional
binding of the symbol, i.e. whether or not the arguments should be
evaluated depends on whether the form was supposed to be a call to a
macro, function, or special form. Think of the problems if you misspell
"cond" in a conditional form!
As for compatibility with the compiler, I'm not sure that this really
matters in this case. I believe that the semantics are not fully
defined in cases where the program is in error, as is the case if an
undefined function is being called.
Maclisp has a "consistency" feature related to this: when a file is
compiled, a warning is produced if a reference was made to a function
not defined in the file (there were declarations that could be used to
explicitly inform the compiler that the function was defined in another
file, in order to prevent the warning and inform it of the function's
semantics (expr vs lexpr vs fexpr)). If you choose to ignore the
warning, then it is your responsibility to realize that the compiled
code is going to assume that there will be a normal function defined at
runtime.
I don't recall whether Common Lisp has something like this; does the
local declaration facility provide this feature? If not, it is too bad,
since some architectures might choose to implement function calls
differently depending on the function's calling sequence. PDP-10
Maclisp does this: it passes arguments in registers if the function
takes less than 5 parameters, and on the stack if it takes more or it
takes an unspecified number (a lexpr, equivalent to a single &REST
argument). If no function definition or declaration is found, the
compiler assumes that it takes a constant number of arguments equal to
the number of parameters in the first call encountered, and complains if
it later encounters a call with a different number of arguments.
--
Barry Margolin
ARPA: barmar@MIT-Multics
UUCP: ..!genrad!mit-eddie!barmar