Top Level

John Lato jwlato at
Tue Jun 23 05:25:02 EDT 2009

On Thu, Jun 18, 2009 at 3:23 PM, Duncan
Coutts<duncan.coutts at> wrote:
> On Thu, 2009-06-18 at 14:26 +0100, John Lato wrote:
>> For me, the largest problem with the current system is one that Simon
>> mentioned under his third point.  While I may know what to expect from
>> a module named "Control.Functor.Pointed", I have no idea what package
>> to import to get that functionality.*  This situation is worse in the
>> cases of multiple packages providing the same modules, such as
>> transformers and mtl.
> Please file a ticket for the cabal program. It's a perfect place to
> stick this feature. ghc-pkg already does it for packages that are
> registered but cabal could do it for all of hackage.

I haven't filed this ticket yet because of some technical issues,
however upon reflection I don't know that it should be filed.

For myself, I was talking about browsing source, such as on hackage.
I do this frequently with packages I'm interested in, particularly if
I'm not at my dev. machine.  Since the module name is completely
orthogonal to the package, if I'm going back through dependencies I
usually have to stop at this point, which often prevents complete
understanding of the code I'm studying.  Re-reading my OP, I can see
that I wasn't very clear.

I'm arguing that, for me at least, orthogonality between module names
and package names is not desirable.  I don't like using the package
name as the top-level either; that seems worse than the current
situation.  I don't have a solution, unfortunately.

Originally I thought this would go well in Cabal, but now I'm not so sure.

In the case of stable packages, all required dependencies are already
listed in the .cabal file, so this wouldn't add anything.

For packages under development, developers would generally know which
packages they intend to use when writing module imports (at least I
would hope so).  I only see this being helpful in the rare case of a
developer deciding to use a new package that isn't registered, not
installing it and not adding it to build-depends:, then forgetting
what package was intended when GHC reports that it can't find module
X.  I have trouble seeing this actually happening.

It's possible that others would find this useful, or that I have a
mistaken impression of cabal's functionality.  If so I would be happy
to file this ticket.  As it stands, though, I don't think it would be
beneficial to me, and I don't want to be making feature requests for
features that I wouldn't even use.


More information about the Libraries mailing list