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
        http://srfi.schemers.org/srfi-77/mail-archive/msg00051.html
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.

Sebastian.