Revamping the numeric classes
Thu, 8 Feb 2001 10:51:58 -0500
Marcin Kowalczyk wrote:
> Wed, 7 Feb 2001 16:17:38 -0500, Peter Douglass
> <email@example.com> pisze:
> > What I have in mind is to remove division by zero as an untypable
> > expression. The idea is to require div, /, mod to take
> > values in their second argument. NonZeroNumeric values
> could be created by
> > functions of type:
> > Number a => a -> Maybe NonZeroNumeric
> > or something similar.
> IMHO it would be impractical.
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. Whether or not an individual developer chooses to do so is
> Often I know that the value is non-zero, but it is not
> statically determined,
If you "know" the value is non-zero before run-time, then that is statically
determined. Otherwise, you don't "know" that.
> so it would just require uglification by
> doing that conversion and then coercing Maybe NonZeroNumeric to
Ugliness is in the eye of the beholder I suppose. For some applications,
every division should be preceded by an explicit test for zero, or the
denominator must be "known" to be non-zero by the way in which it was
created. Forcing a developer to extract a NonZeroNumeric value from a Maybe
NonZeroNumeric value seems equivalent to me.
> It's bottom anyway when the value is 0, but bottom
> would come from Maybe coercion instead of from quot, so it only gives
> a worse error message.
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 most commercial software, the quality of run-time error messages is
far less important than their absence.
> It's so easy to define partial functions that it would not buy much
> for making it explicit outside quot.
> Haskell does not have subtypes so a coercion from NonZeroNumeric to
> plain Numbers would have to be explicit as well, even if logically
> it's just an injection.
If one is aiming to write code which cannot fail at run-time, then extra
work must be done anyway. The only question is whether the language will
support such a discipline.
> Everybody assumes that quot has a symmetric
> type as in all other languages, but in your proposal quot's arguments
> come from completely disjoint worlds.
If it is optional but not required that a developer may disable unsafe
division, then developers who expect arithmetic to work in the usual way
will not be disappointed.
> Moreover, 1/0 is defined on IEEE Doubles (e.g. in ghc): infinity.
This solution doesn't always help with code safety.
Thanks for the response.