Revamping the numeric classes

Marcin 'Qrczak' Kowalczyk qrczak@knm.org.pl
8 Feb 2001 20:45:16 GMT


Thu, 8 Feb 2001 10:51:58 -0500, Peter Douglass <peterd@availant.com> pisze:

> The first part of my question (not contained in your reply) is
> whether it is feasible to disable a developer's access to the
> "unsafe" numerical operations.

import Prelude hiding (quot, rem, (/) {- etc. -})
import YourPrelude -- which defines substitutes

You can "disable" it now. You cannot disable them entirely - anyone can
define present functions in terms of your functions if he really wants.

> Whether or not an individual developer chooses to do so is another
> matter.

Why only quot? There are many other ways to write bottom:
    head []
    (\(x:xs) -> (x,xs)) []
    let x = x in x
    log (-1)
    asin 2
    error "foo"

> If you "know" the value is non-zero before run-time, then that is
> statically determined.

I know but the compiler does not know, and I have no way to convince it.

> It is possible that the developer writes a function which returns a
> nonZeroNumeric value which actually has a value of zero.  However,
> the value of requiring division to have a nonZeroNumeric denominator
> is to catch at compile time the "error" of failing to scrutinize
> (correctly or incorrectly) for zero.

IMHO it would be more painful than useful.

> For most commercial software, the quality of run-time error messages
> is far less important than their absence.

It would not avoid them if the interface does not give a place to
report the error:
    average xs = sum xs / case checkZero (length xs) of
        Just notZero -> notZero
        Nothing      -> error "This should never happen"
is not any more safe than
    average xs = sum xs / length xs

and I can report bad input without trouble now:
    average xs = case length xs of
        0 -> Nothing
        l -> Just (sum xs / l)

-- 
 __("<  Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^                      SYGNATURA ZASTĘPCZA
QRCZAK