[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: arithmetic issues

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.

William D Clinger wrote:
In my view, the primary
rationale for the type-specific operations is to improve the
portability and predictability of Scheme code.  The fixnum
and flonum operations do that by providing a portable base
for a portable implementation of the full numeric tower.
This will allow Scheme programmers to use generic arithmetic
without worrying about implementations that don't provide the
full tower,

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.

(And lest I be accused of advocating the goring someone elses ox, I say that as someone who writes a lot of code with flonums.)

As for assumption 3, type declarations cannot address the
portability and predictability issues unless implementations
are required to interpret those declarations in a consistent
way. [And this has consequences for interpreters.]

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?

Type declarations have the huge advantage of being potentially a general mechanism for providing information on expression types. SRFI-77 provides a specific solution for fixnums and flonums only. Are fixnums and flonums sufficiently more important that the other Scheme data types to warrant this ad-hoc approach?


Dr Alan Watson
Centro de Radioastronomía y Astrofísica
Universidad Astronómico Nacional de México