Date: Mon, 23 Jun 86 21:57:45 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Date: Mon, 23 Jun 1986 21:23 EDT
From: Scott E. Fahlman <Fahlman at C.CS.CMU.EDU>
The section on argument lists consistently says "is an error" and not
"signals an error". I can't remember (or imagine) why these cases
aren't required to signal an error, and I think this should be fixed.
Does anyone disagree? Are there any implementations out there that
don't signal errors when a function is given too many or too few args?
There are plenty of Lisp and Scheme implementations which have a mode
in which such errors are not signalled or reliably detected. The two
which spring to my mind are Maclisp and T, but I suspect that any Lisp
that has a similar go-for-the-speed feature (PSL? Rutgers/UCI Lisp?
...) will fail to signal an error when a compiled function of a fixed
number of arguments is passed a wrong number of arguments. I can't
say I know of any such Common Lisp implementation, but it's certainly
easy to imagine one.
I don't see why this situation should be any different from any other
kind of domain error, like AREF'ing out of bounds. You can certainly
get speed improvements on stock hardware if you don't check number of
arguments (you can eliminate a compare instruction, save space, etc.).
Consistency is more important than speed, of course: if, for whatever
reason, an error must be signalled in this case, then so should errors
be signalled in most places which are now defined to "be an error".
Otherwise, on what principle do you distinguish these two kinds of
situation?
If CL does not come to require number of argument checking, I guess its
time to require *RSET to fill the gap. Seriously. Programmers should
be allowed to say "I want number of arguments checking, damn it" if the
system doesn't automatically provide that.
[After all, if you don't want number of argument checking, you can just
code your lambda list beginning with &optional and ending with &rest
ignore.]