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