problems with Control.Applicative

[Ross Paterson]

On Mon, Oct 16, 2006 at 11:07:13PM -0700, John Meacham wrote:
> The basic issue is that frisby relys on optimizing the parser before
> executing it, so any static information that can be gleaned from the
> built parser is very important to have available. however, the optimizer
> has no way to "see through" an 'fmap' since the functional argument is
> opaque as far as frisby is concerned.
> [...]
> note I don't really consider RULES appropriate here, knowing that the
> optimizer will be able to see through these operations is vital for
> writing a parser that works at all.

I don't follow this part.  The argument of fmap is a semantic action,
which is presumably independent of parsing decisions.  So without
special versions of the operations you lose the ability to simplify
composed actions, which will cost, but how does it prevent the parser
from working at all?

> I would also like to see mapM_ as part of the class definition for
> traversable. For many monads it makes the difference between linear and
> constant space usage and space behavior of haskell programs is hard
> enough to reason about without having to worry about certain rules
> firing.

Do you have an example where Data.Foldable.mapM_ uses linear space,
and can this be avoided with a custom definition of Data.Foldable.foldr?