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

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?

In my opinion, such a global switch is an unfortunate design. As I
pointed out in my earlier email, I would prefer that you classify the
intended use of the fixnum operations, and decide on a per operation
basis whether the operation is most useful for its purpose if it is 'safe'
or if it is 'unsafe.'

One possible design for fixnums in this style is posted as
In essence the idea is to use fixnum as a 'safe' integer subrange, and
have additional 'unsafe' operations for giving access to the underlying
hardware arithmetics as a basis for implementing number types.

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

Is this put forward as an argument in favor of R6RS following in this
tradition? At least you can rely on the fact that you cannot rely on
errors being caught sensibly. In this sense, I would even prefer the
R5RS design over a 'global switch' design.