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.
Dr Alan Watson wrote:
> Would in not be simpler to allow implementations to do
> more or less what they want in the base language but
> mandate that the full tower be available in the
> library? For example, an implementation might implement
> fixnums and bignums in the base language (since for many
> problems ratnums, flonums, and complex numbers are not
> necessary) and then provide all of the rest of the tower
> in the library.
>
> In other words, why force us to have these *horrible*
> flonums in the base language.
Whether the full tower should be required in the base
language, or should be made available as modules in the
standard library, is the very first issue listed in
SRFI-77.
In either case, I think flonums should be in the base
language, because most hardware now supports them much
more efficiently than they could be implemented in a
library module. There is certainly room for different
opinions about this, of course. One purpose of SRFI-77
was to gain a sense of the community's opinion on this
and other issues.
> I presume you refer to whether an implementation
> signals an error when the type of an expression does
> not agree with its type declaration. Isn't the choice
> of signalling or not signalling essentially identical
> to the choice of running the SRFI-77 procedures in
> safe or unsafe mode?
No. Consider fx+, which as defined in SRFI-77 performs
addition modulo hi-lo+1. If the behavior of fx+ is to
be achieved by using type declarations to modify the
behavior of the generic + procedure, then something like
(let ((f (lambda (m n)
(declare (fixnum? m) (fixnum? n))
(the fixnum (+ m n)))))
(f (greatest-fixnum) 1))
must be required to evaluate to lo in all implementations.
This has absolutely nothing to do with the safe/unsafe
mode business.
Will