Hello, I’m developing the Grapefruit library, a library for writing graphical user interfaces and animated graphics using concepts of Functional Reactive Programming. At the moment, all modules of Grapefruit reside under Graphics.UI.Grapefruit but I’m not satisfied with this situation. The reason is that a certain part of Grapefruit just deals with graphics, not user interfaces, and another part deals with basic reactive programming things (several kinds of signals) which could be used in contexts totally different from user interfaces and graphics (for example, sound synthesis). So I thought about spreading Grapefruit’s modules over the module hierarchy. In particular, I thought about splitting the set of modules into the following parts: * Control.Grapefruit and submodules * Graphics.Rendering.Grapefruit and submodules * Graphics.UI.Grapefruit and submodules However, including the name of the library all the time doesn’t seem like a very good idea to me. First, it’s confusing to have three subtrees of the module tree named “Grapefruit” since this looks like if there were three libraries of this name. Second, it’s strange to have Control.Grapefruit beside Control.Monad and Control.Concurrent since “monad” and “concurrent” are concepts whereas “Grapefruit” is a library. Since the Control.Grapefruit subtree would probably only consist of Control.Grapefruit.Signal and submodules, I’d prefer to just use Control.Signal and Control.Signal.*. But this would pose the problem that no other FRP library could use Control.Signal without conflicting with Grapefruit. At the moment, I don’t know of any general rule which gives an answer to these questions. It seems like the current module hierarchy follows multiple guidelines. For example, there are Graphics.Win32 and Graphics.X11 beside Graphics.Rendering and Graphics.UI, the former two referring to existing APIs, the latter two referring to concepts. Below Graphics.Rendering and Graphics.UI there are modules whose names refer to existing APIs again (OpenGL, GLUT, Gtk2Hs). A further question would be if putting FRP signals under Control is sensible at all, or if they should be put under Data. Signals denote functions from time to some value space (but are usually not implemented as simple functions). I’d appreciate any helpful information concerning this topic. Best wishes, Wolfgang