default for quotRem in terms of divMod?

[Isaac Dupree]

(something very odd was going on with that reply-to! trying to send this 
in a sensible way...)

Christian Maeder wrote:
 >
 >
 > Isaac Dupree wrote:
 >> In class Integral, divMod has a default in terms of quotRem.
 >> (quot,rem,div,mod all have defaults as the both-function they're part
 >> of.)  I'm sure divMod is more natural than quotRem to implement for some
 >> types... so why doesn't quotRem have a default in terms of divMod? it
 >> has no default! Then the "minimal to implement" will change from
 >> (toInteger and quotRem) to (toInteger and (quotRem or divMod)).
 >>
 >> Isaac
 >
 > while I don't care if quotRem or divMod should be implemented. I oppose
 > to give both default implementations in terms of the other.
 >
 > Already for the class Eq either == or /= must be defined, with the
 > unpleasant effect that an empty instance like:
 >
 >   instance Eq T
 >
 > leads to a loop (when == or /= is called on elements of type T).
 >
 > The empty instance does not even raise a warning about unimplemented
 > methods (since the default definition is used).
 >
 > I'd rather prefer to remove /= as method of Eq.

I second that this is a problem.  However, I think that compilers are 
perfectly justified in replacing nontermination with a runtime 
error(i.e. exception - the generalization of a call to "error"), and 
also generating warnings when it's unimplemented class methods, and we 
could solve it that way.  I don't know how hard it is to detect 
automatically that two default definitions produce a useless loop... if 
that's too hard, possibly some explicit annotation in the code could be 
done (Already there is an informal convention of saying exactly what 
methods must be implemented, so that should be formalize-able...).  I 
_think_ that for Eq and my Integral proposal, GHC's strictness analyser 
is quite up to the task.

In general, what do we think about replacing certain nontermination with 
an exception, particularly by the compiler's detection? GHC already does 
it very unreliably with the <<loop>> low-level thunk 
something-or-other....  It might be interesting to see how many spurious 
warnings would be generated, if GHC also generated a warning for each - 
i.e. is nontermination ever intentionally used as a _|_ normally?

Isaac