proposal #1

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

As long as the list of functions whose error-checking behavior relies on
the safety switch is kept small, I can live with this proposal.  I'm still
against having to provide multiple definitions of functions, but if only
a dozen or two functions that are normally compiled inline anyway are 
affected, most of the nastier issues are bypassed.  (Perhaps if somebody
could put together a list of these functions, it would give the rest of us
more information as a basis for making a decision?)

However, I agree with Masinter's remarks that saying something "is an error"
in some contexts and "signals an error" in others is bogus.  The situations
in question should remain "an error", whether or not the error is signalled.
I tend to think of this as a means of providing a more user-friendly error
message -- in PSL/PCLS, for example, nearly all of the "is an error"
situations end up signalling *some* error eventually, but it takes some
detective work to figure out that the reason why you got an access violation
is because you tried to do (CDR -3) from compiled code!

Incidentally, currently implementations are free to ignore any declarations
they don't feel like processing (p 161), so presumably if we tie signalling
of errors to the optimize safety declaration, those implementations that
choose to ignore this declaration will not be bound to signal these errors
at all.  This seems like another reason to make the signalling of errors
in these situations something that is strongly encouraged rather than an
absolute requirement.

-Sandra
-------