On 27/03/2012, at 5:18 AM, Jerzy Karczmarczuk wrote:
But I don't care about using (+) = zipWith (+) "anywhere", outside of a programming model / framework, where you keep the sanity of your data. In my programs I KNEW that the length of the list is either fixed, or of some minimal size (or infinite). Your [4,5] simply does not belong to MY rings, if I decided to keep the other one.
And *that* is why I stopped trying to define instance Num t => Num [t]. If "I KNEW that the length of the lists is ... fixed ..." then the type wasn't *really* [t], but some abstract type that happened to be implemented as [t], and that abstract type deserved a newtype name of its own. Naming the type - makes the author's intent clearer to readers - lets the compiler check it's used consistently - lets you have instances that don't match instances for other abstract types that happen to have the same implementation - provides a natural place to document the purpose of the type - gives you a way to enforce the intended restrictions all for zero run-time overhead.