default for quotRem in terms of divMod?
isaacdupree at charter.net
Wed Aug 8 14:45:05 EDT 2007
(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)).
> 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?
More information about the Haskell-prime