Before we proceed, let's make some points clear. For example, OpenGL is currently imported via "Graphics.Rendering.OpenGL". With the reasoning that "Graphics.SomeModule" (instead of "Graphics.Drawing.SomeModule") has no problem ("since we don't really look for packages based upon the module hierarchy but rather on package name, descriptions and categories on Hackage"), one might say that "Graphics.OpenGL" is okay too. Even just "OpenGL" would be fine as well with the same reasoning. We all know that "OpenGL" definitely means the graphics rendering library, and nobody is likely to use such a module name for something else. So let's rename it from "Graphics.Rendering.OpenGL" to "OpenGL". Why use unwieldy "Graphics.Rendering.OpenGL" where we can just, "import OpenGL"? So the question is: Do you agree that "Graphics.Rendering.OpenGL" actually should have been "Graphics.OpenGL" (or just OpenGL) for wieldiness? If you don't, what is your reason? I would like to know. On Mon, Sep 6, 2010 at 1:14 PM, Ivan Lazar Miljenovic < ivan.miljenovic@gmail.com> wrote:

I fail to see a reason for this (well, I can see why it might be desirable from an hierarchical point of view, but not how it will help from a usage point of view since we don't really look for packages based upon the module hierarchy but rather on package name, descriptions and categories on Hackage).

On 6 September 2010 21:57, han wrote:

So the question is: Do you agree that "Graphics.Rendering.OpenGL" actually should have been "Graphics.OpenGL" (or just OpenGL) for wieldiness?

I think Graphics.OpenGL would have sufficed, unless there was sufficient reason to want to group it with other rendering-specific modules. Admittedly, I'm biased, in that I proposed a new top-level Graph.* namespace on the libraries mailing list and out of those few that responded the main response was that there was no point in such a new top-level namespace. -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

creswick:

On Mon, Sep 6, 2010 at 5:29 AM, Ivan Lazar Miljenovic wrote:

...

On 6 September 2010 21:57, han wrote:

...

So the question is: Do you agree that "Graphics.Rendering.OpenGL" actually should have been "Graphics.OpenGL" (or just OpenGL) for wieldiness?

I think Graphics.OpenGL would have sufficed, unless there was sufficient reason to want to group it with other rendering-specific modules.

I'm relatively new to the Haskell community, and one thing that's bugged me a bit is that there doesn't seem to be a convention (aside from common sense) for segmenting the module namespace as there is with Java (my other primary language).

Anyway, I'm curious how module namespace collisions/pollution will be handled in Haskell over the next 5-10 years. Package hiding works in some cases, but it seems like that will fail if you ever need to use capabilities from packages that conflict within the same project.

Well, we have a single global namespace for some 30k modules on Hackage. People are encouraged to partition their packages via top level names, such as Control.* or System.* An tree structure that is roughly followed, http://haskell.org/haskellwiki/Hierarchical_module_names However, when this was planned, I don't think we expected to go from 100 modules to 30k modules in 4 years, and there's been little work on thinking about how to structure the module system at this scale, other than work on explicit package naming and versioning. -- Don