[R6RS] Safe/unsafe mode issues

[Michael Sperber]

[This is a resend of a message I sent to Will personally, in the
interest of having the discussion happen on the list, along with
follow-ups.  I'm sending with his agreement.]

Here are some thoughts on the issues related to safe/unsafe mode.

You probably have more to say on the issue of safe/unsafe mode itself
than I do currently.  Here's a rough draft of what I see currently:

The R5RS currently uses the wordings "is an error" and "signals an
error" to indicate situations where an implementation is free to do
anything (including crash) and "signals an error" where it is required
to notify the user that something bad has happened.  

The R5RS uses these formulations in contexts where
1. a procedure is called on an argument it is not prepared to accept,
   i.e. a bug in the program, 
2. an exceptional situation occurs in the environment (I/O), 
3. something not-so-clearcut happens (arithmetic)

Most (all except Stalin?) Scheme implementations offer a "safe mode"
which makes each situation described as "is an error" actually signal
an error.  Some compiled implementations (and some interpreted ones as
well) offer an "unsafe mode" where the argument checks needed to
detect #1 (and #3?) from the above list are elided, and thus no error
is signalled.  R5RS mandates no "safe mode."

I assume that R6RS, like R5RS, will use distinct wordings to describe
erroneous and exceptional situations, and will differentiate in the
same way between situations where the behavior of the implementation
is unspecified, and situations where an implementation is required to
"signal an error."  (More on the wording issue later.)  (There's a
third, separate wording to describe situations which aren't
exceptional, but where the behavior is still unspecified, as as
wrt. evaluation order, inexact arithmetic and so on.  This message
isn't about that at all.)

I think the R6RS should mandate a "safe mode" that requires an
implementation to run a program, which is available in source code, and
which relies only on libraries specified as part of R6RS, in such a
way that *all* exceptional situations must "signal an error."  It
should also not prohibit implementations from providing unsafe or safe
mode selectively, i.e. via special compile switches or something, or
saying allowing a piece of code to selectively use "the unsafe version
of fixnum arithmetic" or something like that.

Moreover, I think that the R6RS should specify more precisely what
"signal an error" means, namely that it should raise an exception
with a specified condition.  (I'm assuming a SRFI-34/35-like framework
for exceptions and conditions.)

For the reasons I outlined in my Snowbird talk, I think "is an error"
and "signal an error" are unfortunate wordings, especially if applied
indiscriminately both to program bugs and exceptional situations in
the environments---I think the wording in the report and the condition
system should make that distinction clear.  I tentatively suggest the
word "error" to describe an exceptional situation in the environment,
and the word "bug" to describe a mistake made in the program by the
programmer.  (I'm not particularly attached to either word.)  A litmus
test to distinguish a bug from an error is determining whether the
program could have been written in such a way as to avoid the
exceptional situation in all cases---in the case of argument-type or
-range errors, this is often possible.  Thus, some condition objects
describe bugs, and some describe errors.  (In a SRFI-35-like condition
system, a condition object could also describe both, and that's
sometimes appropriate.)

This in turn suggests replacing the wording "is an error" by "is a
bug" and "signals an error" to "raises a bug condition" in most places
where they currently appear in the R5RS.  Moreover, safe mode would
mean that "is a bug" always raises a bug condition, and unsafe mode
would mean that "is a bug" behaves in an unspecified manner.

-- 
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla