2009/1/17 Andrew Coppin <andrewcop...@btinternet.com>: > 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 > _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe