2008/11/9 Johannes Waldmann :

NB: Wasn't there a time (before "do") when "list" notation (brackets) would work in any monad? And "map" was a method in "Functor", and we had "class Functor m => Monad m", etc. Well well well times have changed.

Sure, I believe the feature was called "monad comprehensions". AFAIK it was removed because it gave confusing error messages to new users of the language (what is this Monad thing? I just want a list of stuff!). List comprehensions really have diverged from being a special "do" notation at the list monad, since you are able to write comprehensions like [(x, y) | x <- xs | y <- ys], and it's not clear how to define "zip" for a monad - but perhaps there is some extension of a monad where it makes sense? All the best, Max

On Sun, 2008-11-09 at 10:15 +0000, Max Bolingbroke wrote:

2008/11/9 Johannes Waldmann :

...

NB: Wasn't there a time (before "do") when "list" notation (brackets) would work in any monad? And "map" was a method in "Functor", and we had "class Functor m => Monad m", etc. Well well well times have changed.

Sure, I believe the feature was called "monad comprehensions". AFAIK it was removed because it gave confusing error messages to new users of the language (what is this Monad thing? I just want a list of stuff!).

List comprehensions really have diverged from being a special "do" notation at the list monad, since you are able to write comprehensions like [(x, y) | x <- xs | y <- ys], and it's not clear how to define "zip" for a monad - but perhaps there is some extension of a monad where it makes sense?

As far as I can tell, no one actually uses parallel list comprehensions. With any luck, the same will be true for generalized list comprehensions.

On Sun, 2008-11-09 at 19:18 +0000, Andrew Coppin wrote:

Derek Elkins wrote:

...

As far as I can tell, no one actually uses parallel list comprehensions. With any luck, the same will be true for generalized list comprehensions.

Generalised? Heck, I don't use list comprehension at all! :-P

Perhaps you should! :-) When I first started with Haskell I kind of had the idea that list comprehensions were just for beginners and that 'real' hackers used just concatMaps and filters. A couple years later I 'rediscovered' list comprehensions and I now use them frequently. There are many cases in real programs where simple and not-so-simple list comprehensions are the clearest way of expressing the solution. In particular the easy support for refutable pattern matching in the generators allows some succinct and clear code. Just a random example out of Cabal: warn verbosity $ "This package indirectly depends on multiple versions of the same " ++ "package. This is highly likely to cause a compile failure.\n" ++ unlines [ "package " ++ display pkg ++ " requires " ++ display (PackageIdentifier name ver) | (name, uses) <- inconsistencies , (pkg, ver) <- uses ] Pretty concise and clear I think. Duncan

Mitchell, Neil wrote:

In general:

if boolean then [value] else []

Can be written as:

[value | boolean]

Is there any specific reason why this is valid?

On Mon, 2008-11-10 at 18:20 +0000, Andrew Coppin wrote:

Mitchell, Neil wrote:

...

In general:

if boolean then [value] else []

Can be written as:

[value | boolean]

Is there any specific reason why this is valid?

Is there any specific reason to dis-allow it? The grammar here looks something like (NB: I didn't double-check the report): list_compr ::= [ value | generator* ] generator ::= boolean | pat <- list | let binds One particular special case is where there is exactly one generator, which has three further special cases: [ value | boolean ] [ value | pat <- expr ] [ value | let binds ] These are all valid because they are special cases of the general list comprehension syntax; the de-sugarings are all just special cases of the general list comprehension de-sugaring rules: [ value | ] = [ value ] [ value | boolean, generators ] = if boolean then [ value | generators ] else [] [ value | pat <- expr, generators ] = expr >>= \ x -> case x of pat -> [ value | generators ]; _ -> [] [ value | let binds, generators ] = let binds in [ value | generators ] So the special cases simplify to [ value | boolean ] = if boolean then [ value ] else [] [ value | pat <- expr ] = expr >>= \ x -> case x of pat -> [ value ]; _ -> [] [ value | let binds ] = let binds in [ value ] Why wouldn't this work? jcc

On Mon, 2008-11-10 at 18:48 +0000, Andrew Coppin wrote:

Jonathan Cast wrote:

...

On Mon, 2008-11-10 at 18:20 +0000, Andrew Coppin wrote:

...

Mitchell, Neil wrote:

...

In general:

if boolean then [value] else []

Can be written as:

[value | boolean]

Is there any specific reason why this is valid?

Is there any specific reason to dis-allow it? The grammar here looks something like (NB: I didn't double-check the report):

list_compr ::= [ value | generator* ] generator ::= boolean | pat <- list | let binds

Hmm, that's interesting. I didn't know that a Boolean was a valid generator.

(Presumably this has the effect of filtering?)

The only time I use list comprehensions is when I quickly want a Cartesian product. I wasn't really aware it could filter as well.

Funny. About the only time I use list comprehensions is when I want a generalized filter. Serious computations get the do-notation, instead. (And sometimes I *have* to use do-notation for filtering, because I need an error monad (usually Maybe) for other reasons). jcc

On Mon, 2008-11-10 at 18:50 +0000, Duncan Coutts wrote: [...]

If you meant, why is it allowed rather than banned then I guess the answer is because it is orthogonal. The rules naturally handle that case and there was no particular reason to ban it, even if it is somewhat unusual.

"Unusual?" This is the motivation of list comprehensions. In naive set theory, set comprehensions are one way of an equivalence between predicates and sets. It's the Cartesian product aspect that should be considered unusual if anything. The binding aspect of list generators corresponds to naming the parameters of the predicate and then the Cartesian product aspect is simply the fact that a binary predicate, say, is a unary predicate on a binary Cartesian product.

Duncan Coutts wrote:

On Sun, 2008-11-09 at 19:18 +0000, Andrew Coppin wrote:

...

Generalised? Heck, I don't use list comprehension at all! :-P

Perhaps you should! :-)

When I first started with Haskell I kind of had the idea that list comprehensions were just for beginners and that 'real' hackers used just concatMaps and filters.

A couple years later I 'rediscovered' list comprehensions and I now use them frequently. There are many cases in real programs where simple and not-so-simple list comprehensions are the clearest way of expressing the solution. In particular the easy support for refutable pattern matching in the generators allows some succinct and clear code.

I don't actually use *lists* all that much - or at least not list transformations. And if I'm going to do something complicated, I'll usually write it as a do-expression rather than a comprehension.

Just a random example out of Cabal:

warn verbosity $ "This package indirectly depends on multiple versions of the same " ++ "package. This is highly likely to cause a compile failure.\n" ++ unlines [ "package " ++ display pkg ++ " requires " ++ display (PackageIdentifier name ver) | (name, uses) <- inconsistencies , (pkg, ver) <- uses ]

Pretty concise and clear I think.

Erm... yeah, it's not too bad once I change all the formatting to make it clear what's what. Wouldn't it be a lot easier as a do-block though?

On Mon, 2008-11-10 at 18:19 +0000, Andrew Coppin wrote:

I don't actually use *lists* all that much - or at least not list transformations. And if I'm going to do something complicated, I'll usually write it as a do-expression rather than a comprehension.

...

Just a random example out of Cabal:

warn verbosity $ "This package indirectly depends on multiple versions of the same " ++ "package. This is highly likely to cause a compile failure.\n" ++ unlines [ "package " ++ display pkg ++ " requires " ++ display (PackageIdentifier name ver) | (name, uses) <- inconsistencies , (pkg, ver) <- uses ]

Pretty concise and clear I think.

Erm... yeah, it's not too bad once I change all the formatting to make it clear what's what.

Wouldn't it be a lot easier as a do-block though?

I don't think so: ++ unlines $ do (name, uses) <- inconsistencies (pkg, ver) <- uses return $ "package " ++ display pkg ++ " requires " ++ display (PackageIdentifier name ver) Of course reasonable people may disagree. It's mostly aesthetics. Duncan

Well, my original post wasn't that negative ... Indeed "then f [by e]" seems a nice idea *but* the point was that I'd like to have this in any monad. The type of f in "then f" should be m a -> m b, not just m a -> m a, because then you don't need special syntax for "group", which is somewhat like [a] -> [[a]] ? J.W.