Re: Two functions for everything?

[David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>]

    Date: Mon 30 Jun 86 11:09:16-MDT
    From: SANDRA <LOOSEMORE@UTAH-20.ARPA>

    Setting the safety switch only seems like half the story to me.  You still
    have to provide some way to specify what error checking a given function
    does for each value of the safety setting.  The reason why I would prefer
    to see this mechanism part of the language spec, rather than left up to
    each implementation, is that there is no real distinction between "system"
    code and "user" code in Lisp.  Since most CL implementations are, in fact,
    written *in* CL, chances are they would have some internal, high-level
    hooks to do this anyway.  (Although I suppose there is at least one
    masochistic implementor out there who actually *likes* writing code in
    assembly language!  :-))  So why not make these hooks available to the
    user?

I'm still not sure I understand you, but I have thought up one scenario.
I was thinking that what safety affected were things that "are an error"
as defined by the language.  This includes such things as AREF out of
bounds, calling a function with the wrong number of arguments, etc.
Under this view, if I compile
	(defun foo (a) (car a))
with safety 0, the implementation may encode CAR inline.  If I compile
it with safety 1, speed fast, it might compile as if I had written
	(defun foo (a) (check-type a 'list) (and a (car a)))
If I compile it with safety 3, speed slow, space small, it might compile
as
	(defun foo (a) (call-car's-full-checking-entrypoint a))
Some other settings might make it compile as
	(defun foo (a) (call-car's-no-checking-entrypoint a))
[Seems silly for CAR, but consider a slightly larger function, such as
AREF.]

Maybe what you are saying is that the user might write
	(defun foo (a) (check-type a 'list) (and a (car a)))
but might want to allow the check-type to be avoided if a caller of FOO
was compiled with safety 0.  I don't know what to do about this.  One
theory, which I think I believe, is that if a programmer puts in
explicit checking, that checking is always run.

    The sort of thing I have in mind is like a declarative form that contains
    the assertions about the arguments to a particular function, and the
    "safety level" at which to test each assertion.  It would be up to the
    implementation to figure out how to wrap the tests around the body of the
    function.

    Personally, I think having to write error checking code at all is a
    nuisance, and trying to manage multiple levels of error checking sounds
    like a real nightmare.  Unless we can come up with some abstractions for
    dealing with the complexity, I suspect that a lot of implementors are
    going to avoid messing with it entirely.

If I write a function that I expect other programmers to call, I usually
put in some error checking.  I don't find it a nuisance, I find it a
benefit to make sure (a) they get the error messages they deserve at a
reasonable time, and (b) to make sure assumptions about the data I make
are valid (because they passed the tests).

Isn't this is a tug-of-war between speed and robustness on stock
hardware?  Special hardware is usually designed to do both.  CLtL tries
to give users the option of speed or robustness.  I'm under the
impression this is a compile-time-only choice, and that you would like a
run-time choice as well?