[Haskell] placing modules in the module hierarchy

[Wolfgang Jeltsch]

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