Assorted documentation fixes

[fumieval]

No description provided.

[sjakobi]

Thanks! :)

[sjakobi]

One more thing I noticed.

[fumieval]

I removed this because it has nothing to do with lists. A similar, and up-to-date example is already in the comment ofprimMapLazyByteStringBounded

[sjakobi]

Wow, thanks a lot, @fumieval! :)

@Bodigrim what do you think about the exposure of the internal Contravariant and Monoidal classes?

[Bodigrim]

Honestly, I'm quite uncomfortable with internal modules exposed at all. It would be so much better to have a separate bytestring-internal package, but not much can be changed now. I would rather not make the situation worse by exposing more stuff, especially type classes, especially if the only benefit is fixing haddock links.

BTW what about adding a disclaimer to internal modules alike to http://hackage.haskell.org/package/containers-0.6.2.1/docs/Data-Map-Internal.html? This could simplify their maintenance after the next major bump.

[fumieval]

OK, I removed the commit exposing Monoidal and Contravariant.

[sjakobi]

BTW what about adding a disclaimer to internal modules alike to http://hackage.haskell.org/package/containers-0.6.2.1/docs/Data-Map-Internal.html? This could simplify their maintenance after the next major bump.

I'm not very comfortable with just slipping this in in this PR. I think the stability guarantees and versioning policy for the Internal modules should be discussed on the issue tracker and possibly on the libraries list first.

My concern is that it feels like there was an implicit stability guarantee for these modules, and users may have based their code on such guarantees.

[Bodigrim]

It would be nice to review which parts of internal modules proved to be useful and expose them through non-internal modules.

[sjakobi]

LGTM! :)

[Bodigrim]

@hsyl20 could you please take a look as well?

[sjakobi]

@hsyl20 could you please take a look as well?

Since the changes are only in the documentation, and since there hasn't been any activity a week, I think 2 approvals are good enough.

If there are any problems in this PR, we can easily fix them later.

@hsyl20, maybe we should try to clarify which PRs should require your approval and which don't. The current situation is a bit vague.

[sjakobi]

Thanks again for all the fixes, @fumieval! :)

[dcoutts]

Nice. Thanks.