
I'll try to be more specific: the trouble is that the Haskell.Plus hierarchy doesn't group libraries by functionality, it groups them by status (language extensions). And Haskell.Language doesn't have anything in common with Haskell.Plus functionality-wise.
Ok, I acknowledge that. I think we seem to be gradually coming to a consensus on Marcin's point - that the functionality of a library should be paramount in the naming scheme, regardless of implementation, standardness, portability, etc. This is good.
Briefly, what I had in mind is: each module in the hierarchy has a status, ranging from experimental to standard. The closer to "standard", the less likely the interface is to change. The hierarchy as a whole would need a version number, so that applications can conditionally compile code for changing libraries if they need to.
In addition to standard/experimental there needs to be portable/non-portable for libraries that depend on or provide language extensions. A "standard" library would only be able to depend on certain extensions (eg. FFI and module-namespace only).
This seems reasonable in principle. There are quite a few attributes of each library module that we need to know, quite separate from the actual name and source code. Again, it begs the question of how this meta-information will be maintained. One common database for all Haskell compilers/interpreters would be ideal. Sounds like about the right size for a small student project actually.... Has anyone got any small students? :-) Regards, Malcolm