> From: bear <xxxxxx@sonic.net>
>> On Wed, 23 Nov 2005, Sebastian Egner wrote:
>> Mike wrote:
>>> From this, and several other messages in the SRFI 77 archives, I'm
>>> getting the impression there's some misunderstanding here about the
>>> nature of safe/unsafe mode, as alluded to in the document.
>>
>> Always possible. I understand safe/unsafe mode to mean that there is
>> some form of global switch (either compile-time or run-time) that is
>> controlling whether certain arithmetic operations raise an exception
>> when an error condition happens---or just press on. I understand that
>> the 'unsafe' mode allows a compiler to produce code without range
>> checking or tag-bit removal, with all sorts of performance benefits. Is
>> this what you mean by safe/unsafe mode?
>
> Actually, I think all he said was that it controls whether error
> checking is required or optional - making all the "is an error"
> language relating to exact/inexact arithmetic read as "an error is
> signalled" when safe mode is on, and leaving it as is (and signalling
> at the discretion of the implementation) when it's off.
>
> You envision a different kind of control, where it's possible to
> specify that errors should *not* be detected or signalled, and I
> don't think that's what this says.

- somewhat paradoxically, it's not clear that halting a program upon
  encountering what is deemed an error, is more "safe" than a nuisance.

- alternatively a typically useful value for potentially erroneous
  calculations may be returned by default for all functions for which
  an explicit exception handler has not been defined, in the absence
  of a global exception handler being explicitly enabled.

  (in other words, likely useful values are returned by default, or
  may halt the program's execution if a global exception handler is
  enabled explicitly; as may be desired during program development,
  but not likely otherwise)