Sebastian Egner <xxxxxx@philips.com> writes:

> I think a global mode controlling the behavior of the
> arithmetic operations is a fundamentally bad idea.

>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.

> This approach was used in PASCAL, and it did not work
> as well in practice as it was hoped for because the
> proof obligation raised by switching to 'unsafe mode' is
> "the entire program is arithmetically correct," which can
> occasionally be challenging to actually prove.

I'm not sure how the comparison with PASCAL goes---safe/unsafe mode is
about (dynamic) tag/type checking, which doesn't happen in PASCAL.  It
has nothing to do with "arithmetic correctness."  Specifically,
safe/unsafe mode, as in SRFI 77, has no impact on overflow checking or
contagion.  The only thing it does (essentially) is to control
whether

(fl+ 5+3i 1.2)

must signal an error or do something unspecified.  Unsafe mode, as it
currently stands in SRFI 77, only has effect on flonum and fixnum
arithmetic.

A typical implementation that implements unsafe mode is probably going
to have the program crash.

I want to point out that, as far as the general idea is concerned,
R5RS gives you *only* unsafe mode---very few unspecified situations in
R5RS are guaranteed to signal an error, most are allowed to be
silently ignored or lead to a crash.

I may be misunderstanding you, or you might hold your position in
light of this interpretation.  (The same holds for everyone else on
the list.)  It'd be useful to know, so I encourage people to post.

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