Bringing back Monad Comprehensions (in style)

[George Giorgidze]

Simon Marlow <marlowsd <at> gmail.com> writes:

> 
> On 06/10/2010 00:26, Max Bolingbroke wrote:
> > 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
> 
> I wonder how much that extension is actually used, e.g. in all of 
> Hackage?  Could we deprecate it?
> 
> Cheers,
> 	Simon
> 

I personally, do not have strong feelings about the zip comprehension
notation. Unfortunately, I do not now how widely is this feature used by the
Haskell community.

I have just checked that in GHC 6.12 -XTransformListComp does not imply
-XParallelListComp. The zip comprehension notation is supported as a separate
language extension.

As a start, one could implement -XMonadComp that supports standard list
comprehensions (i.e., generators, filters and let binding) and subsequently
extended it with 'order by' and 'group by'.

This should only require GHC extension and does not need addition of new type
classes/subclasses to the standard library. Monad and MonadPlus (for
filtering) should be enough.

Afterwards, if -XParallelListComp remains as a supported extension of GHC, one
can identify a suitable (sub) type class for that and ensure that
-XParallelListComp plays nicely with -XMonadComp.

Cheers, George