Proposal: Reserved module namespace for packages on Hackage

David Menendez dave at
Mon Aug 18 20:48:12 EDT 2008

On Mon, Aug 18, 2008 at 8:03 PM, Isaac Dupree <isaacdupree at> wrote:
> David Menendez wrote:
>> Implementation costs are minor.
> There is a serious cost: Sometimes another package is *supposed to* provide
> the same interface, including the same module names (e.g. forks or
> reimplementations.  e.g. SOE). If Hackage rejected them, we would have a
> serious problem once people started depending on any package using a Lib.
> name.

Would we? How many packages out there are drop-in replacements? Even
things like Data.List.Stream, which is a drop-in replacement for
Data.List, uses a different module name. The packages I've seen that
abstract over other packages tend to use preprocessor commands to get
the right modules.

I can see your point about forks. That's one case where it might be
better to use the same module names as a different package. But I'm
leery of relying on two modules with the same name having the same

The ideal solution would be something like the package mounting
proposal, but that has a major implementation cost. This is more of a
stop-gap measure that could be implemented today.


> But it's not hard to pretty much avoid conflicts; you don't even need the
> Lib. prefix, you can just use the package name as your top-level module
> name. (right? or does hackage arbitrarily reject some module names?)

As I understand it, Hackage complains if you use a top-level name that
isn't on the approved list. Putting the package name at the top-level
is also a possibility, but putting it one level down is more

Really, all my proposal needs is to add "Lib" to the list of
acceptable top-level names, and to have some document on the web
explain what it's for.

Dave Menendez <dave at>

More information about the Libraries mailing list