Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site mit-eddie.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!ihnp4!mit-eddie!barmar
From: barmar@mit-eddie.UUCP (Barry Margolin)
Newsgroups: net.lang.lisp
Subject: Re: Common Lisp Issues
Message-ID: <4494@mit-eddie.UUCP>
Date: Wed, 19-Jun-85 01:50:08 EDT
Article-I.D.: mit-eddi.4494
Posted: Wed Jun 19 01:50:08 1985
Date-Received: Thu, 20-Jun-85 20:29:53 EDT
References: <2337@cornell.UUCP>
Reply-To: barmar@mit-eddie.UUCP (Barry Margolin)
Organization: MIT, Cambridge, MA
Lines: 40


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