Marcin Kowalczyk wrote:

Wed, 7 Feb 2001 16:17:38 -0500, Peter Douglass 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