Argument lists

["Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>]

Yes, you're right.  Wrong number of arguments should be treated like
AREF'ing out of bounds or type violations.  The manual currently says
that these things are errors, but not that they must signal an error.
A good implementation will signal errors in most of these cases unless
compiled for maximal speed and minimal safety, but implementations are
not currently required to do this.

You ask about philosophy.  Here's my current view -- it has evolved a
bit in the last couple of years:

There are three good reasons to document something as "being" an error,
but not as "signalling" one: first, it might be a place where we imagine
someone will want to extend the language, and where we want to leave
that possibility open; second, it might be an error that (perhaps only
on some architectures) is just impossible to detect with a reasonable
amount of effort; third, it might be a place where a few cycles can be
saved by not checking for the error.

It seems to me that, if we were doing this from scratch, we ought to
treat these cases differently.  Specifically, I would go with four
classes of errors:

1. Errors that must always be signalled, and that portable code can
count on having signalled.  These are errors where little speed-up would
result from allowing them to go undetected.

2. Errors that must normally be signalled, but that need not be if code
is compiled with safety = 0.  Most of the current "is an error"
conditions, including wrong number of args, out-of-bounds array refs,
and most type violations, would fall in here.

3. Errors that are too hard to detect, and which need not be signalled.
Non-terminating code might be an example.

4. Errors that must be signalled unless an implementation deliberately
chooses to extend the language in this area, and documents that it has
done so.  I'm not sure how much of this we ought to allow.

I suspect that this is too large a change to think about for the current
set of revisions.  No legal and portable user code would be affected,
but I suspect that some implementations would require a lot of revision
in order to comply with the tightened requirements of case 2.

-- Scott