List comprehensions have overlapping functionality with map and filter. filterM caters for the situation in which the predicate returns a Bool wrapped in a monad (well, an Applicative, to be precise). mapM does something similar for mapping functions whose result is wrapped in an Applicative.

In case you want to reproduce the behaviour of mapM with a list comprehension, sequence comes to the rescue. But how can filterM be replaced with a list comprehension? In other words, how can a predicate which returns a Bool inside a context, be used as a guard in list comprehensions?

Below are trivial examples exploring the 2x2x2 space (filter/map, function/comprehension, plain/monadic) of above observations, only I don't know how to write fcm. How can fcm be fixed so that it has the same value as ffm?

import Control.Monad (filterM)

predicate = (>3)
convert = (*10)
predicateM = Just . predicate -- Just represents an arbitrary monad
convertM = Just . convert
data_ = [1..5]

ffp = filter predicate data_
ffm = filterM predicateM data_
fcp = [a | a <- data_, predicate a]
fcm = [a | a <- data_, predicateM a]

mfp = map convert data_
mfm = mapM convertM data_
mcp = [ convert a | a <- data_ ]
mcm = sequence [ convertM a | a <- data_ ]

Edit:

It's important to note that the versions whose name ends in m must use a convertM or predicateM: the plain convert and predicate are unavailable in those situations; that's the whole point of the question.

Background information

The motivation arises from having a bunch of functions (here is a simplified collection, which is hopefully representative)

convert :: a -> r -> b
predicate :: a -> r -> Bool
big :: [a] -> r -> [b]

big as r = [ convert a r | a <- as, predicate a r ]

which are begging to be refactored in terms of Reader ... and one of which (big) uses one of the others (predicate) as a predicate in listcomp guard.

Refactoring works just fine, as long as the listcomp is replaced with a combination of mapM and filterM:

convertR :: a -> Reader r b
predicateR :: a -> Reader r Bool
bigR :: [a] -> Reader r [b]

bigR as = mapM convertR =<< filterM predicateR as

The trouble with this is that, in real life, the listcomp is much more complex, and the translation to mapM and filterM is far less clean.

Hence the motivation for wanting to keep the listcomp even when the predicate has turned monadic.

Edit 2

The real listcomp is more complex, because it combines elements from more than one list. I've tried to extact the essence of the problem into the following example, which differs from Edit 1 in that

• The listcomp in big takes data from more than one list.


• 
  predicate takes more than one value as input.


• 
  convert has been rename to combine and takes more than one value as input.


• Similar changes for the Reader versions.

.

combine :: r -> (a,a) -> b
predicate :: r -> (a,a) -> Bool
big, big' :: r -> [a] -> [b]

big r as = [ combine r (a,b) | a <- as, b <- as, predicate r (a,b) ]
big' r as = map (combine r) $ filter (predicate r) $ [ (a,b) | a <- as, b <- as ]

combineR :: (a,a) -> Reader r b
predicateR :: (a,a) -> Reader r Bool
bigR, bigR' :: [a] -> Reader r [b]

bigR = undefined
bigR' as = mapM combineR =<< filterM predicateR =<< return [ (a,b) | a <- as, b <- as ]

big' is a rewrite of big in which combine and predicate are extracted from the listcomp. This has a direct equivalent in the Reader version: bigR'. So, the question is, how can you write bigR which should be

1. Not significantly uglier than bigR'
   


2. As direct a translation of big as reasonably possible.

At this stage I'm tempted to conclude that bigR' is as good as it's going to get. This implies that the answer to my question is:

• keep the listcomp for constructing the cartesian product


• move predicate and combine out of the expression into a filter and a map respectively


• in the monadic version, replace filter and map with filterM and mapM (and $ with =<<).


• uncurry the predicate and combiner functions: the listcomp works equally well with curried and uncurried versions, but the map-filter combination needs them to be curried. At this stage this is probably the biggest price to pay for losing the ability to use the listcomp.

Personally, I can't figure out a way to do it with just a list comp, but this might get you closer? (I've listed some intermediate steps I went through so you can take it in a different direction if you need).

-# LANGUAGE MonadComprehensions #-

predicateM = return . (>3)
[[a | True <- predicateM a] | a <- [1,2,3,4,5]] 
 :: (Num b, Ord b, Control.Monad.Fail.MonadFail m) => [m b]
[[if b then Just a else Nothing | b <- predicateM a] | a <- [1,2,3,4,5]]
 :: (Num a, Monad m, Ord a) => [m (Maybe a)]
[[bool Nothing (Just a) b | b <- predicateM a] | a <- [1,2,3,4,5]]
 :: (Num a, Monad m, Ord a) => [m (Maybe a)]
catMaybes <$> sequence [[bool Nothing (Just a) b | b <- predicateM a] | a <- [1,2,3,4,5]]
 :: (Monad f, Num a, Ord a) => f [a]

filterM' p xs = catMaybes <$> sequence [[bool Nothing (Just a) b | b <- p a] | a <- xs]

There may be something neater with a ListT?

EDIT: Another approach, although it spews some warnings about ListT giving unlawful instances..

unListT (ListT x) = x
filterM'' p xs = unListT [a | (a,True) <- ListT $ mapM (x -> return . (x,) =<< p x) xs]

EDIT2: Okay I got it down to a single comprehension!

filterM''' :: (Traversable m1, Monad m2, Monad m1, Alternative m1) => (b -> m2 Bool) -> m1 b -> m2 (m1 b)
filterM''' p xs = [[a | (a,b) <- mlist, b] | mlist <- mapM (x -> return . (x,) =<< p x) xs]

EDIT3: Another approach, because I'm not sure on precisely what you need access to.

filterM' p xs = [x | x <- filterM p xs]

Then, nest the comprehensions to obtain access to the "inner" element type eg. filtering and mapping,

filterMap f p xs = [[f x | x <- mlist] | mlist <- filterM p xs]

import Control.Monad.Trans.Reader
import Control.Monad (filterM)

The question was motivated by the desire to take some functions of the form

f :: x -> y -> z -> a ; f = undefined
p :: x -> y -> z -> Bool ; p = undefined
u :: [x] -> [y] -> [z] -> [a]

and replace them with similar ones within some context (Reader in this example):

fR :: x -> y -> z -> Reader r a ; fR = undefined
pR :: x -> y -> z -> Reader r Bool ; pR = undefined
uR :: [x] -> [y] -> [z] -> Reader r [a]

At the core of the question, one of the original functions has a multi-input list comprehension that uses the other functions for combining and filtering purposes:

u xs ys zs = [ f x y z | x <- xs, y <- ys, z <- zs, p x y z ]

The question addresses the difficulties of implementing the equivalent, contextful, uR function; specifically the apparent loss of ability to use a list comprehension and its conveniences.

There is a fairly neat translation of u into an implementation that combines a list comprehension, filter and map. This is shown as u' below. u' has a direct translation to the contextful version, uR:

u' xs ys zs = map ucf $ filter ucp $ cartesian xs ys zs
uR xs ys zs = mapM ucfR =<< filterM ucpR =<< return (cartesian xs ys zs)

In the above, the list comprehension is packed up in cartesian

cartesian xs ys zs = [ (x,y,z) | x <- xs, y <- ys, z <- zs ]

and the solution requires the original functions (p, f, pR and fR) to be uncurried:

ucp = uncurry3 p ; ucpR = uncurry3 pR
ucf = uncurry3 f ; ucfR = uncurry3 fR

uncurry3 :: (a -> b -> c -> r) -> (a, b, c) -> r
uncurry3 f = (a,b,c) -> f a b c

Maybe this solution can be sugared with a monad comprehension, but I haven't the time to think about that right now.