In Scala, I find the syntax used in for comprehensions a bit confusing. Specifically, the use of the keyword for. Clearly, this is a concession to simulating looping constructs from other languages, particularly looping over collections. The fact that for constructs compile to map, flatMap, filter and foreach reinforces this view. However, the facility is more general. Consider the use of for comprehensions in the Parser library. The code style looks more like a Haskell do block. It relies on the fact that the parser combinators return "collections" that are either empty or contain one element. Thus, the "loops" are really a chain of expressions, the chain being broken by the first parse failure. This is analogous to looking at an SQL inner join and realizing that the cardinality of all of the relations involved in the join have cardinality zero-or-one.
Haskell's do seems to suffer from a similar problem. The construct is intended to be used with the celebrated Monad type. But the word do suggests simple sequencing -- not general combinators. It doesn't help that the monadic unit operation is named return. No wonder people get confused by monads.
In both Scala and Haskell, I think that the mixed metaphors cause grief. At least in my case, the supposedly helpful choices of keywords made it harder to understand the deeper truth. In both cases, perhaps it would have been better to have two levels of abstraction: an upper level that uses only friendly keywords like for, do and return, and a lower level that only uses monadic or combinator terms. Keep the two worlds separate.
