Ben Lippmeier wrote: >> to monads. If the idea is most clearly expressed >> as a monad, use a monad. If the idea is most >> clearly expressed recursively, write it recursively >> (but perhaps wrap it in "return"). > > There is no inherent advantage or disadvantage > > Perhaps the "inherent disadvantage" is that functions written in the > monadic style must have different types compared with their > conceptually similar non-monadic functions.. > > mapM :: Monad m => (a -> m b) -> [a] -> m [b] > map :: (a -> b) -> [a] -> [b] > > filter :: (a -> Bool) -> [a] -> [a] > filterM :: (Monad m) => (a -> m Bool) -> [a] -> m [a] > > foldl :: (a -> b -> a) -> a -> [b] -> a > foldM :: (Monad m) => (a -> b -> m a) -> a -> [b] -> m a > > Some would say "but they're different functions!", others would say > "close enough". Heh... I recently was experimenting with this separation... Check this out. If the Num class had been defined without having "Eq" as a prerequisite, you could do something like this: ---8<--------------------------------- class MyNum v where (.+) :: v -> v -> v instance MyNum Int where (.+) a b = a + b instance (Monad m, MyNum v) => MyNum (m v) where (.+) a b = do ra <- a rb <- b return (ra .+ rb) two = return 2 :: IO Int three = return 3 :: IO Int main = do result <- two .+ three putStr $ show result ---8<--------------------------------- I defined an operator to add Ints and made it work fine in a monadic environment. See what happened? Easy. Problem is, Num is a subclass of Eq (for no apparent technical reason, only for expressivity), which prevents using this mechanism with it. Eq could have been defined to parameterize on the boolean value (using multiparameter classes and functional dependencies, so no wonder it isn't): ---8<--------------------------------- class MyEq v b | v -> b where (.==) :: v -> v -> b instance MyEq Int Bool where (.==) a b = a == b instance (Monad m, MyEq v b) => MyEq (m v) (m b) where (.==) a b = do ra <- a rb <- b return (ra .== rb) two = return 2 :: IO Int three = return 3 :: IO Int main = do cond <- two .== three putStrLn $ show cond ---8<--------------------------------- > I imagine this would be an absolute pain for library writers. Notice > that we get Data.Map.map but no Data.Map.mapM - or perhaps there's > some magical lifting combinator that I am not aware of? The above works great. Not with the standard libraries, of course, but you can always use it in your own classes. I'm not sure yet what the "catch" will be, but it sounds like a pattern worth investigating. The same thing, I suspect, can be done with arrows. Maybe some day syntactic sugar can be added to overlay functions safely like this without having to manually create a class and two instances for it. Just beware: to make this JCAB