[Haskell-cafe] Conceptualizing Functor vs Performance

[Yuri Lensky]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140628/ff90dc90/attachment.html>