problems with Control.Applicative

[John Meacham]

I really like the ideas behind Control.Applicative, but find it
troublesome to use in practice.

mainly, the minimalist choice of what to make class methods makes it
very difficult to use for various applications.

an example that is bugging me right  now is that it is the _perfect_ fit
for my frisby parser generator, however, I am unable to use it because
the primitives 'pure' and 'fmap' and '<*>' which Control.Applicative is
built on are not suitable low level primitives in practice (despite
being sufficient in theory).

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.

the rub is plain old fmap is almost never used, but all the useful
things Control.Applicative provides are:

in particular:

(<$) :: Functor f => a -> f b -> f a
(*>) :: Applicative f => f a -> f b -> f b
(<*) :: Applicative f => f a -> f b -> f a
optional :: Alternative f => f a -> f (Maybe a)
some :: Alternative f => f a -> f [a]
many :: Alternative f => f a -> f [a]

(along with pure)

are sufficient to encode pretty much every reasonable parser, and all of
them have a special internal representation independent of 'fmap'

it is rather disapointing that I can't make use of this library as it is
in ghc when it is such a good fit for the application. Perhaps in the
next revision we can move these (or a suitable subset) functions into
the class?


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 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. Also, relying on rules means not being able to use polymorphic
combinators built upon these primitives without taking special steps to
ensure the rules can still fire.

I really like the ideas behind Applicative,Traversable, and Foldable.
but I feel these issues will unecesarrily hurt their utility.

        John

--
John Meacham - ⑆repetae.net⑆john⑈