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