prettyprinter has very long module names

[sjakobi]

I remember being frustrated by the long module names when working on dhall, especially when I had to reformat qualified imports after adding an import like

import qualified Data.Text.Prettyprint.Doc.Render.Terminal as Pretty

The basic idea would be to replace the Data.Text.Prettyprint.Doc prefix with just Prettyprinter.

The change would probably happen in multiple phases:

1. Move all the code into the corresponding shorter Prettyprinter modules, but re-export everything from the old modules.
2. Wait a few versions in case there are any problems.
3. Deprecate the old modules.
4. Remove the old modules after waiting a bit longer.

Thoughts?

[sjakobi]

I still like this idea. @quchen, what do you think?

[quchen]

I totally agree the module names are too long. This was brought up to me shortly after the initial release of the library already, but I did not think it was a good time to do something about it. If there is a non-breaking way to go about this, go ahead! I would hate to have maintainers to have to hack around this using lots of #ifdefs just to save some import code – the maintenance effort for others should really be minimal. But given a long enough transitional period and deprecated reexports, I don’t see why not.

[sjakobi]

This is the deprecation plan that I have included in the changelog for v1.7.0 and the associated releases for pp-ansi-terminal and pp-convert-ansi-wl-pprint:

• Start deprecation in early 2021.
• Remove the modules after a deprecation period of at least one year.

[sjakobi]

@istathar has a nice recommendation for de-cluttering the module overview, that we should consider using when we properly deprecate the old module hierarchy.

If you use

{-# OPTIONS_HADDOCK hide #-}
in a module header alongside the language pragmas it'll suppress that module from appearing in generated Haddock output. I use it to hide internal modules without making it impossible to access them. Works really well for deprecated modules, too.

[quchen]

Resolved in #203