Ticket #3870 (new feature request)
Avoid Haddock-links to the Prelude
| Reported by: | waern | Owned by: | |
|---|---|---|---|
| Priority: | low | Milestone: | 7.4.1 |
| Component: | Documentation | Version: | 6.12.1 |
| Keywords: | Cc: | ||
| Operating System: | Unknown/Multiple | Architecture: | Unknown/Multiple |
| Type of failure: | Documentation bug | Difficulty: | |
| Test Case: | Blocked By: | ||
| Blocking: | Related Tickets: |
Description
If you're generating documenatation that links to the base package, you will see that some links to standard types go to the Prelude and some to the hierarchical libararies. For example, Int goes to Prelude.Int, while Either goes to Data.Either.Either.
This happens because the Prelude imports some types from the hierarchical libraries, while some are imported directly from internal GHC modules (e.g. GHC.Base). In the first case, the hierarchical module is choosen as the best place to link to since it's closer than the Prelude in the topological sort to the original module. In the latter case, the hierarchical module and the Prelude are of equal number of imports away from the original module, so none is considered a better place to link to. In this case one of the modules is arbitrarily chosen and it happens to be the Prelude.
I think it would be nice if the links would always go to the hierarchical libraries. Maybe the best way to achieve that would be to add {-# OPTIONS_HADDOCK NotHome #-} to the Prelude. This flag is not yet documented (I should get around to that). It tells Haddock to prefer linking to another module if one is available.
