Re: Two functions for everything?

[SANDRA <LOOSEMORE@UTAH-20.ARPA>]

  From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>

    Date: Mon 30 Jun 86 08:52:34-MDT
    From: SANDRA <LOOSEMORE@UTAH-20.ARPA>

    Yeah, but where in CLtL do we provide a way to make functions with multiple
    entry points?  I certainly don't want to have to hand-code every single
    function that does optional error checking in assembly language (or
    whatever).  The point I was trying to make was that, if we are serious
    about making multiple levels of error checking part of the language, we
    should also provide some high-level constructs for specifying what error
    checking goes on when.  Multiple entry points would be one way to implement
    such a construct....

  Why do you think CLtL has to specify how this is done?  It is completely
  in the domain of the implementation of the compiler, the linker and the
  compiled function format.  The only thing CLtL needs to specify is how
  to get what you want, and I think it already has that with the safety
  setting.

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?

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.

-Sandra
-------