I am having trouble consolidating a performance-based data representation decision I would like to make against the concept of a "functor". The question can be reduced to the following: Conceptually I think that Data.Vector /should/ be a functor. More specifically, I see no CONCEPTUAL reason that it shouldn't be possible to define some "efficient" container-like object (for example for fast Matrix operations for unboxable numbers, but something that still works for a symbolic variable type) that chooses to represent its data as a Data.Vector.Unboxed if possible, but chooses some more generic structure (perhaps a strict list or a generic Data.Vector) if that is not the case. I haven't found such a functor, and can't seem to implement it on my own. The point is that in theory there is no true constraint on the type of the object being contained so it SHOULD be a Functor/Traversable/etc., the representation simply changes to something more efficient only if possible, and decays to a more generic type gracefully if necessary. Perhaps there is some type hackery that can be done with TypeFamilies? I.E. define some container type "data C a = (ListType a) a", but I haven't found a generic way to do this. Finally, I understand that "efficient" data structure can be problem-dependent, but I have no problem defining many different such "generic" types for different applications. The simplest example would be something like (invalid Haskell): (Data.Vector.Unboxed.Vector v a) => data instance (ListType a) = v (Data.Vector.Generic.Vector v a) => data instance (ListType a) = v data instance (ListType a) = ([]) Of course implementing fmap is a whole separate issue. The point is I do not think this is the right way/possible, but am wondering what the "true" solution is. Thanks.