[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: safe/unsafe mode
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