Are list comprehensions a major part of Haskell

Question

I looked at various Haskell resources on the web, before buying the book, Real World Haskell. Being otherwise excellent, it doesn't seem to contain anything about list comprehensions which I saw mentioned in the various websites I looked at. Could this just be because they are generally unused in well written Haskell for some reason, or is it something more complex? For instance the odd looking syntax could conceivably just be some amalgamation of operators I haven't seen yet.

Answer 1

List comprehensions are mentioned briefly in Chapter 12.

I find myself using combinations of map and filter much more often than list comprehensions in Haskell, but in Python I would more frequently use a list comprehension. So I think part of it is personal style.

Once you understand how to use each part of a list comprehension, what more is there for you to learn in regards to list comprehensions? You have your inputs, your conditions/guards, and your function applications for the returned list. I don't really see a warranted need for a large section about list comprehensions in a book.

Answer 2

List comprehensions are syntactic sugar for binding (as in a monad's bind) lists.

The other syntactic sugar for that is the do-notation. Imho it is nicer, and the big plus is that it works for all monads.

If list comprehensions didn't exist, I believe there would be one less thing to learn, and nothing was lost (you can use do-notation instead).

The argument in favor of list comprehensions is that it would make it clearer to the user that it is a list. Imho a type signature would work better for that.

Answer 3

Haskell is defined by having a small set of core language functionality surrounded by a rich set of syntactic choices. List comprehensions are one choice, but they provide nothing that the monad sugar that RWH spends the entire book building up intuition for doesn't also provide. There are many cases where Haskell provides two syntaxes for the same thing, let vs. where, case and combinator oriented programming style, and list comprehensions and monad sugar.

List comprehensions were originally implemented as monad comprehensions, a fact which changed in the "great monomorphization revolution of '98" (aka Haskell '98). In fact, the design of LINQ in .NET languages derives heavily from the older monad comprehension design. List comprehensions could be far more general than they are, but were deliberately crippled to make them yield easier to understand error messages.

Given a finite amount of paper, you have to choose what material to emphasize, and RWH avoids talking about them for the most part so you don't fall into the trap of thinking of lists as anything special.

That said, there is a brief mention of them in Chapter 12. By that point sufficient intuition has been built up for the underlying concepts that they aren't really a danger.

In the end, the name of the book is Real World Haskell. It wants to teach you good real world programming techniques. A number of Haskellers (not all) avoid list comprehensions because the notation doesn't scale well, and because eventually, you may want to come back in and retrofit a monad transformer or something and would wind up rewriting whole swathes of comprehension code in monadic style anyways.

Answer 4

I see three mentions of list comprehension in RWH.

Answer 5

List comprehensions appear mostly in small list-processing examples, many of which are intended to be overtly mathematical in flavor. When you start getting into the larger apps such as are covered in Real World Haskell, list processsing is proportionally a much smaller part of the code. And as noted, it's often just as convenient to use map, filter, fold, zip, and so on, as it is to use a list comprehension.

So

• In real-world Haskell program, only a small fraction of code processes lists.

• Only a small fraction of list-processing Haskell code comes out significantly nicer when written using a list comprehension.

Almost all of the list comprehensions I write turn out to produce lists of pairs. I'm not sure that anything should be read into that, however.