Hi, Long ago (back in 2001), there was a message in the Haskell mailing list, archived e. g. here: http://www.mail-archive.com/haskell@haskell.org/msg08187.html and what it refers to is here: http://www.cs.york.ac.uk/fp/libraries/layout.html which goes for "Graphics.UI. etc" I used this approach in my script to cabalize Fudgets: everything was placed below "Graphics.UI.Fudgets" (original Fudgets library used plain module space). I am currently working on another stuff related to Haskell GUI for web browser, and us the same approach: everything goes under Graphics.UI.<library name> So, I think, despite this creates longer paths in the hierarchy, the more specialized the stuff is, the deeper in the hierarchy it should be pushed. Slightly off topic, this is IMHO the same problem that we have in Linux packages/filesystem layout: every package containing binaries, places them into say /usr/bin. Then, if the two packages have a binary with the same name, this leads to conflict (HSSFFIG has a program named "splitter". Another package in Debian also had a binary with the same name. they conflicted. To resolve it' I'd have to rename my binary to say hsffig-splitter. Should every package be installed into its own subtree, such conflicts wouldn't arise). So, to my personal opinion (which is in agreement with the proposal mentioned) each package has to have its own tree not crossing with other packages' tree. So, I'd suggest for the Grapefruit library: whatever is specific to this library, goes under Graphics.UI.Grapefruit. Whatever may be commonly used elsewhere (say some useful data structures) might go under "Data". So, if FRP signals are usable outside the Grapefruit, they might go to Control. Thanks. -- Dimitry Golubovsky Anywhere on the Web