These libraries are different in the way they store data and in the interface. vectors-space is abstract, while your library offers an easier interface. For example vector-space defines an additive group and an affine space while you have a function translate3x.

No, I too have an additive group (well, it's called AbelianGroup, not AdditiveGroup); translate3 and the like are just utility functions, in a separate module. But yes, I see now that this part of the vector-space interface is actually not that far from mine (though the linear maps part is very different). I think the best would be to have one abstract library. Then hmatrix imports

this library and overloads the functions.

Here are some random questions to think about, regarding a general abstract interface: - do you want to use type families? It's not really portable - what about type inference? The more abstract the interface, the more type annotations the user have to write (for example, with the current OpenGL binding you cannot simply write (Vertex3 1 0 0), which is somewhat annoying). - vectors are bimodules over both scalars and matrices. How would you encode this? If you want to go with the abstract way, you would want modules over rings. But that can be problematic. - are there performance costs associated with the abstraction? - the more concrete the types, the more operations and/or more efficient algorithms are possible. It's pretty hard to encode things like `algorithms working with matrices over principal ideal domains' with the Haskell type system. - what about dense/sparse matrices? How would the interface handle the fact that you would want to have different realizations of the same abstract type in the same program? - clearly one cannot expect a general interface to cover all the possible use cases. How to make it extensible? etc etc. Of course, prove me wrong if you can! I'm not at all against abstraction, just being pragmatic here. Balazs