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