[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: safe/unsafe mode

This page is part of the web mail archives of SRFI 77 from before July 7th, 2015. The new archives for SRFI 77 contain all messages, not just those from before July 7th, 2015.

Sebastian Egner <sebastian.egner@xxxxxxxxxxx> 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

(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

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