John Goerzen
The major features [of MissingH] are:
* A general-purpose modular logging infrastructure * A virtual filesystem component (similar to VFS in Gnome, but written in Haskell) * A configuration file parser, compatible with Python's and Perl's, which can also modify and generate config files and do variable interpolation * A bunch of tools for setting up pipes to/from processes * Tools to format numbers as quantities, with default configs for the SI system (1000-based) and binary system (1024-based) * Tools to track the progress of long-running actions and display a status bar on the terminal * Pure-Haskell un-gzip code, *DBM infrastructure, etc * MIME and email parsers.
Each of those bullet points sounds to me like a useful individual package in its own right. Certainly I had no idea that MissingH contained many of these things, and if I had wanted them, the single name MissingH would not have suggested that I look there. I think they could profitably be split off.
* Assorted list, string, regexp, bit, pointer, etc. utilities
By contrast, I guess these parts are what I always believed the "MissingH" name to refer to. They are in some sense missing from the original Haskell'98 libraries. But, given that the evolving 'base' package is now pretty-much the de facto standard, rather than the immutable 'haskell98' package, I see no reason for these functions to remain separate from it. There is a community process for adding new functions to the 'standard' libraries. Use it! Let these functions be "missing" no more! If they are truly useful, they will be adopted without too much fuss. (Note, when I say 'base', I might actually mean 'regex-*' or something else. I don't want to prejudge where these things live, just to encourage you to propose them to the whole Haskell community.)
I initially wrote it that way to make resolving dependencies easier for end users. Also, it still has utility because modules make use of each other's features. The list and string functions are used almost everywhere, for instance. HVFS support is also fairly pervasive.
With Cabal packages, you can express dependencies on other packages with ease. Provided it is not a rats nest of mutual recursion, this is the way to go.
Modules are currently named things like MissingH.List, MissingH.IO.HVFS, MissingH.ProgressMeter, etc.
I guess these could go to System.ListExt, System.IO.HVFS, System.Console.ProgressMeter, etc.
In general, yes. [ The bikeshed approacheth, but System.ListExt is not very descriptive - what is wrong with proposing additions to Data.List itself? ]
Could, and should, any of this be integrated into the Haskell libraries project? (That set of libraries formerly known as fptools)
Where your packages are stored, and how they are maintained, is a separate decision from the choices (a) to use the standard packaging mechanism, and (b) to divide the monolith up into smaller, more manageable chunks.
How could greater community participation be encouraged, while still encouraging quality control?
For quality, just maintain your own public darcs repositories. You get to decide which patches to apply and which to reject. For greater community participation, I think the simple strategy of splitting the libs up into smaller, more grok-able packages is the important first step. Publicity about what each package is good for is the next. Then, if you get significant numbers of users for these libraries, patches will arrive. :-) Regards, Malcolm