On 5 October 2010 15:41, George Giorgidze <giorgidze at gmail.com> wrote:
> 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