On 5 October 2010 15:41, George Giorgidze
One can also look at how recently introduced 'order by' and 'group by' constructs generalise to monad comprehensions. If that works, one could implement even more "stylish" monad comprehension notation.
They do: see the comments by MichaelAdams at http://haskell.org/haskellwiki/Simonpj/Talk:ListComp. Last I checked, the code there was slightly buggy but correct in spirit. What *doesn't* generalise is the zip comprehensions extension: [(x, y) | x <- xs | y <- ys] == zip xs ys The required operator :: m a -> m b -> m (a, b) is that of the ZipList applicative functor, not that of the standard applicative functor for lists. Probably to generalise this you need a new typeclass like this one (copied from my own library): class Functor z => Zippable z where -- Naturality: -- fmap (first f) (zip_ as bs) == zip_ (fmap f as) bs -- fmap (second f) (zip_ as bs) == zip_ as (fmap f bs) -- -- Information preservation: -- fmap fst (zip_ as bs) == as -- fmap snd (zip_ as bs) == bs zip_ :: z a -> z b -> z (a, b) zip_ = zipWith_ (,) zipWith_ :: (a -> b -> c) -> z a -> z b -> z c zipWith_ f as bs = fmap (uncurry f) (zip_ as bs) It probably needs some extra laws to say how it interacts with the Monad operators.
* Do you think that it would be hard to integrate this extension into current GHC codebase?
Pretty easy IMHO. The list comprehensions are already half-set up for this job, and you should be able to reuse lots of the code that handles the monad notation desugaring.
* Have you already thought about how to generalise 'order by' and 'group by' to monad comprehensions?
See above.
* Have you already thought about how to address the original objections to the monad comprehension notation?
I thought it was rejected because it caused newbies to get confusing type error messages: they expected *list* error messages but got errors mentioning a scary *Monad* thing. Personally I'm not sure how to solve that, but if it's only available as an extension this won't cause a problem. Cheers, Max