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
_______________________________________________
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
