2009/1/17 Andrew Coppin
Eugene Kirpichov wrote:
No, a functor is a more wide notion than that, it has nothing to do with collections. An explanation more close to truth would be "A structure is a functor if it provides a way to convert a structure over X to a structure over Y, given a function X -> Y, while preserving the underlying 'structure'", where preserving structure means being compatible with composition and identity.
As far as I'm aware, constraints like "while preserving the underlying structure" are not expressible in Haskell.
Yes, but they are expressible in your mind so that you can recognize a functor and design you program so that it does satisfy this constraint, thus removing a large faulty piece of the design space. Also, you can write a QuickCheck test for fmap (f . g) = fmap f . fmap g and fmap id = id.
instance (Monad m) => Functor m where fmap f ma = do a <- ma; return (f a)
While that's quite interesting from a mathematical point of view, how is this "useful" for programming purposes?
In the same sense as monoids are, see my previous message. If you mean the usefulness of a Functor typeclass in Haskell, it's in the fact that everywhere where you'd like to convert a structure over X to a structure over Y (for example, the result of a monadic computation), you simply write 'fmap f structure' and it works the right way, if the structure has an instance for Functor (many structures do). I know I'm being a bit abstract, but that's the way I percept it. do filename <- toLowerCase `fmap` readLine ....
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe