From: wren ng thornton
I think at this stage in the game, OpenGL.* is probably better. The way I see it there are two rather different kinds of modules (or module collections):
* For module collections which have high utility across many different packages/programs (e.g. Data.Map, Control.Monad), having functionality-based names is helpful for solving name-clash and functionality-discovering/remembering issues. These modules are truly stand-alone "libraries" and are extremely composable (with other module collections) and extremely decomposable (from module collection into the constituent modules).
* However, there are other collections of modules which are not "libraries" so much as "frameworks". While they're still (usually) composable, they're typically not decomposable. Often these are the results of taking an executable and shaving off some of the front-end details. Because of the non-decomposability, it makes sense to me to give each of these a top-level module name. Under the top-level they should be organized by functionality--- in the terms of the framework itself, not in the general terms shared by the "libraries".
+1. 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. I do think that the module namespace hierarchy is useful, and I am not convinced that the top level should be flattened, but I think it would be good to have some sort of tighter connection between package name and either the top level or second level module name, even if only as a convention. John Lato * I actually do know, because it's my example. It's in category-extras. I was able to find this in Hayoo!, but not Hoogle.
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. http://hackage.haskell.org/trac/hackage/ Duncan
On Thu, Jun 18, 2009 at 3:23 PM, Duncan
Coutts
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. Sincerely, John
participants (2)
-
Duncan Coutts -
John Lato