Proposal #1

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

I don't think that your severity proposal can possibly fly.  The
decision about whether to signal an error is a function of two things:
the severity of the effects of the error and the cost of detecting it.
The cost of detecting various kinds of errors varies tremendously from
one implementation to another (and the danger posed by non-detection can
vary as well) so we can't really create a scalar ranking of errors and
standardize it across all implementations.  This is a multi-dimensional
problem.

I thought we had discussed your second point at some length, when Sandra
Loosemore expressed dismay at having to provide two versions of all
built-in functions, but I'll try again using your AREF example.

If we adopt proposal #1 and then decide that aref-out-of-bounds is a
Class 2 error, your SAFE-SLOW-2D-AREF must check for and signal
such errors.  So there must be a built-in AREF function that does this
checking.  I would be surprised to learn of an implementaiton that does
not already provide this function.

Under the same assumptions, your UNSAFE-FAST-2D-AREF would be allowed to
call the same built-in function, or the implementors could choose to
provide a second, quick and dirty AREF function that would be called
instead.

I doubt that many implementations will bother to provide this second
version of AREF.  People interested in speed will allow the system to
compile their AREF calls inline, and that's where omitting the check can
buy you some speed.  In general, most of the potential Class 2 errors
are things that really ought to be checked for, but where the
error-checking can be too burdensome if the call is open-coded.

The main burden to implementors will be to put optional error-checking
code into various inline code expansions.  Most implementations already
compile in checks if the user asks for safety, but not all do.

-- Scott