Editing User:Benmachine/Overqualified modules (section)

=== Redundant disambiguation ===

One could argue that keeping module names long reduces the risk of collision. It's true that specifying more information in the module name might reduce the chance of some other module clashing with it, but often people confuse “information content” with “textual length”: clearly, grouping all monad-related modules under <tt>Control.Monad</tt> instead of just <tt>Monad</tt> is not going to stop two implementations of <tt>Reader</tt> from interfering with each other. So keep just the meaningful component of the name: what, after all, could possibly be named <tt>Monad</tt> except for a module housing the <tt>Monad</tt> class and related utility functions? Likewise <tt>Applicative</tt>, <tt>List</tt>, <tt>Exception</tt>, <tt>IO</tt>: all sorts of concepts are clearly going to exist only once in Haskell. Those that don't are no better served being <tt>Control.Monad.Reader</tt> than <tt>Monad.Reader</tt>.

If you really want to avoid name collisions, take a leaf from syb's book: previously under the hierarchy <tt>Data.Generics</tt>, which not only suffered from <tt>Data</tt>-itis but also adequately described any generic programming mechanism, syb is starting to move over to the new, more specific <tt>Generics.SYB</tt> hierarchy. This drops the useless <tt>Data</tt> prefix and instead uses a component – the name of the package – that is very likely to be unique to this particular design and implementation. We appear to lose some "generality", but in reality the knowledge that you were using SYB in particular was probably already encoded in your program, since other generics libraries will have made different design decisions. The new name also emphasises the position of syb as ''a'' generics library, not ''the'' generics library – on an equal footing with Uniplate and other similar tools.