What is the reason to store a list of values, instead of a running-sum/count pair?

[leftaroundabout]

The list monoid has the annoying property of being inefficient (caching concerns aside) when left-mappended in a long chain. This is particularly annoying since that's the way the Writer monad combines values.

The following definition should be equivalent to the current one as far as the intended use is concerned, and has no such problem:

data Average a = Average { weight :: Int
                         , averageAcc :: a
                         }

instance Num a -- or better: VectorSpace a
               => Monoid (Average a) where
  mempty = Average 0 0
  mappend (Average w₀ a₀) (Average w₁ a₁) = Average (w₀+w₁) (a₀+a₁)

average :: Fractional a => Average a -> a
average (Average w a) = a / fromIntegral w

Note that this does not interfere with the functor instance: the extra constraint is really only needed – and rightly so! – for Monoid. About Applicative I'm not sure, but I think this should also work somehow.

Is it really sensible to copy list's Applicative instance anyway, for that matter?

[leftaroundabout]

The Applicative instance should probably be

instance Applicative Average where
  pure = Average 1
  Average w₀ a₀ <*> Average w₁ a₁ = Average (w₀*w₁) (a₀ a₁)

[eborden]

The problem with pure = Average 1 is that it causes extremely confusing results when utilizing this instance. I do not think Applicative is an appropriate instance for this monoid.

[leftaroundabout]

@eborden you may be right, I also don't subscribe to making every type an instance of every class just because it's possible. Although pure = Average 1 by itself seems perfectly intuitive to me; do you have any particular example of confusing results that would arise from the instance I proposed?

[eborden]

I'm going to move the conversation about the Applicative instance to #4