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⑈