Henning Thielemann schrieb:
On Mon, 6 Apr 2009, Kalman Noel wrote:
I'm not complaining, and I'm not sure what I mean :) I may like a scheme where functions operating on a type or type class live in a module seperate from the type (class) definition, so you could import a specific module to get only, say, (Ring, (*), one, ...). But that would be too tedious in the Haskell hierarchical module system, which is why I was asking about others.
It was precisely my goal to bundle the type with the functions that operate on it. Why do you want to separate them?
Sorry for the huge delay. Here are some reasons why I think such a seperation can be handy: (1) If I need an import just to be able to write a type annotation (e.g. I'm passing around a value of that type, but not doing anything specific to it), then I can just import a module that gives me the relevant types. (2) Similarly, I can, say, calculate with complex numbers and refer to them as Complex Double without importing (qualified) the Complex implementations of exp, signum etc., which I won't ever have to use directly, thanks to the relevant type class instances. (3) I can refer to a Ring as a Ring, rather than a Ring.C. (1) may not be so important, given that I can just write an import list. (2) means seperating interface and implementation (without hiding the implementation). (3) is just a matter of taste.