Revamping the numeric classes

[Peter Douglass]

Marcin Kowalczyk wrote:
> Wed, 7 Feb 2001 16:17:38 -0500, Peter Douglass 
> <peterd@availant.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 
> NonZeroNumeric
> > 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
another matter.  

> 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
> NonZeroNumeric.

  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 zero. 
 
  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.
--PeterD