Opened 4 years ago

Last modified 18 months ago

#10328 new bug

Control.Monad exports lead to weird Haddocks

Reported by: dfeuer Owned by:
Priority: low Milestone:
Component: Core Libraries Version: 7.10.1
Keywords: Cc: core-libraries-committee@…
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Documentation bug Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


Control.Monad exports, and therefore documents, the Functor class (but only the fmap member) and the Monad class. It does not export, and therefore does not document, the Applicative class. This is all pretty weird. Since Functor is in the prelude (and probably most/all alternate preludes), is there actually a reason to export it from Control.Monad?

Change History (5)

comment:1 Changed 4 years ago by dfeuer

Type: feature requestbug

comment:2 Changed 4 years ago by hvr

For one, it's demanded by H2010 (see The question is rather, why H2010 doesn't have any Data.Functor module (which I guess is related to the fact that it ended up in Control.Monad...)

Btw, this could be yet another use-case for #4879 (if we decide to slowly phase out the re-export from Control.Monad) :-)

comment:3 Changed 4 years ago by ekmett

Currently it is demanded by the report and backwards compatibility.

It is worth evaluating whether we can eliminate such re-exports from Control.Monad in the future, but such would require a good deal of community buy-in.

I for one would support ultimately removing the redundant re-exports from Control.Monad and all over the mtl should such a thing be put to a poll / proposal. They were a repeated thorn in our side when we were trying to figure out if we even _could_ do something like offer alternate Preludes, etc.

comment:4 Changed 3 years ago by thomie

Owner: ekmett deleted

comment:5 Changed 18 months ago by dfeuer

Priority: normallow
Note: See TracTickets for help on using tickets.