[Haskell-cafe] placing modules in the module hierarchy

[Dimitry Golubovsky]

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