Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site cornell.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!vax135!cornell!jts
From: jts@cornell.UUCP
Newsgroups: net.lang.lisp
Subject: Re: Common Lisp Issues
Message-ID: <2337@cornell.UUCP>
Date: Mon, 10-Jun-85 12:41:57 EDT
Article-I.D.: cornell.2337
Posted: Mon Jun 10 12:41:57 1985
Date-Received: Tue, 11-Jun-85 04:46:53 EDT
Sender: jts@cornell.UUCP
Organization: Cornell Univ. CS Dept.
Lines: 29

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)