While digging through Haskell’s `base`

libaries the other day, I came across these surprising instances for `Data.Complex`

, which seems intended to be a nice way to work with complex numbers:

```
instance Applicative Complex
instance Monad Complex
```

It’s strange to see monads and applicatives for this kind of thing in the first place (is a tuple `Num n => (n, n)`

a monad?). However, i found it especially interesting how these specific instances also lead to some pretty weird numeric behavior, if you’re expecting `Complex`

to act anything like complex numbers in math.

First of all, `pure`

puts its argument in both the real and imaginary part. So \(\mathrm{pure}\:1\) becomes \(1 + i\)

```
$ pure 1 :: Complex Double
1.0 :+ 1.0
```

This is because `pure`

just pairs its argument with itself: `pure a = a :+ a`

. Because `Complex`

was made so general, it doesn’t have access to a notion of “zero”, which you’d need if you wanted to make this act more like `pure a = a :+ 0`

.

The bind operation has more going on, so has more opportunity to seem bizarre from a math standpoint. If you try to add a “plain” number to a complex, you get oddities like this:

```
$ 1 :+ 2 >>= (+1)
2.0 :+ 0.0
```

And binding to a function of a complex does this piecewise thing (whereas \((2+3i)(4+5i)\) in math would be \(-7+22i\)).

```
$ 2 :+ 3 >>= (*(4 :+ 5))
8.0 :+ 15.0
```

Here’s the implementation that makes this behavior happen. It’s applying the bound function to both sides, but then a possible “combining step” is cut in favor of just taking the real part of the real part, and the imaginary part of the imaginary part.

```
instance Monad Complex where
a :+ b >>= f = realPart (f a) :+ imagPart (f b)
```

This seems like a case of being a little too parametric for your own good. (It’s also a case of seeing a monad where a monad may not really be the best model.) So, these instances on `Complex`

act more like they’re for a general “pairing” than they are for complex numbers.