Are there any documented anti-patterns for functional programming? [closed] - scala

Question

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Next month I'm going to work on a new R&D project that will adopt a functional programming language (I voted for Haskell, but right now F# got more consensus). Now, I've played with such languages for a while and developed a few command line tools with them, but this is a quite bigger project and I'm trying to improve my functional programming knowledge and technique. I've also read a lot on the topic, but I can't find any books or resources that document anti-patterns in the functional programming world.
Now, learning about anti-patterns means learning about other smart people failures: in OOP I know a few of them, and I'm experienced enough to choose wisely when something that generally is an anti-pattern, perfectly fit my needs. But I can choose this because I know the lesson learned by other smart guys.
Thus, my question is: are there any documented anti-patterns in functional programming? Till now, all of my collegues told me that they do not know any, but they can't state why.
If yes, please include one single link to an authoritative source (a catalogue, an essay, a book or equivalent).
If no, please support your answer by a proper theorem.
Please don't turn this question in a list: it is a boolean question that just requires a proof to evaluate the answer. For example, if you are Oleg Kiselyov, "Yes" is enough, since everybody will be able to find your essay on the topic. Still, please be generous.
Note that I am looking for formal anti-patterns, not simple bad habits or bad practices.
From the linked wikipedia article on Anti-Patterns:
... there must be at least two key elements present to formally distinguish an actual anti-pattern from a simple bad habit, bad practice, or bad idea:
some repeated pattern of action, process or structure that initially appears to be beneficial, but ultimately produces more bad consequences than beneficial results, and
an alternative solution exists that is clearly documented, proven in actual practice and repeatable.
Moreover by "documented" I mean something from authoritative authors or well known sources.
The languages that I'm used to are:
Haskell (where I'm really starting to think that if code compiles, it works!)
Scala
F#
but I can also adapt knowledge about anti-patterns documented in other functional languages.
I searched a lot in the web, but all the resources I've found are either related to OOP or to function layout (define variable at the beginning of the function, and the like...).

Answer 1

The only anti-pattern I've seen is over-monadization, and since monads can be incredibly useful this falls somewhere in between a bad practice and an anti-pattern.
Suppose you have some property P that you want to be true of some of your objects. You could decorate your objects with a P monad (here in Scala, use paste in the REPL to get the object and its companion to stick together):
class P[A](val value: A) {
def flatMap[B](f: A => P[B]): P[B] = f(value) // AKA bind, >>=
def map[B](f: A => B) = flatMap(f andThen P.pure) // (to keep `for` happy)
}
object P {
def pure[A](a: A) = new P(a) // AKA unit, return
}
Okay, so far so good; we cheated a little bit by making value a val rather than making this a comonad (if that's what we wanted), but we now have a handy wrapper in which we can wrap anything. Now let's suppose we also have properties Q and R.
class Q[A](val value: A) {
def flatMap[B](f: A => Q[B]): Q[B] = f(value)
def map[B](f: A => B) = flatMap(f andThen Q.pure)
}
object Q {
def pure[A](a: A) = new Q(a)
}
class R[A](val value: A) {
def flatMap[B](f: A => R[B]): R[B] = f(value)
def map[B](f: A => B) = flatMap(f andThen R.pure)
}
object R {
def pure[A](a: A) = new R(a)
}
So we decorate our object:
class Foo { override def toString = "foo" }
val bippy = R.pure( Q.pure( P.pure( new Foo ) ) )
Now we are suddenly faced with a host of problems. If we have a method that requires property Q, how do we get to it?
def bar(qf: Q[Foo]) = qf.value.toString + "bar"
Well, clearly bar(bippy) isn't going to work. There are traverse or swap operations that effectively flip monads, so we could, if we'd defined swap in an appropriate way, do something like
bippy.map(_.swap).map(_.map(bar))
to get our string back (actually, a R[P[String]]). But we've now committed ourselves to doing something like this for every method that we call.
This is usually the wrong thing to do. When possible, you should use some other abstraction mechanism that is equally safe. For instance, in Scala you could also create marker traits
trait X
trait Y
trait Z
val tweel = new Foo with X with Y with Z
def baz(yf: Foo with Y) = yf.toString + "baz"
baz(tweel)
Whew! So much easier. Now it is very important to point out that not everything is easier. For example, with this method if you start manipulating Foo you will have to keep track of all the decorators yourself instead of letting the monadic map/flatMap do it for you. But very often you don't need to do a bunch of in-kind manipulations, and then the deeply nested monads are an anti-pattern.
(Note: monadic nesting has a stack structure while traits have a set structure; there is no inherent reason why a compiler could not allow set-like monads, but it's not a natural construct for typical formulations of type theory. The anti-pattern is a simple consequence of the fact that deep stacks are tricky to work with. They can be somewhat easier if you implement all the Forth stack operations for your monads (or the standard set of Monad transformers in Haskell).)