On Mon, Aug 18, 2008 at 8:03 PM, Isaac Dupree
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 interface. 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. http://hackage.haskell.org/trac/ghc/wiki/PackageMounting
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
future-proof.
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