Hi, Josef Svenningsson posted a comment on my blog today that got me to thinking. He suggested that people may be "intimidated by the size of MissingH, confused by the undescriptive name, and don't quite know what's in there." And I think he's right. I've been passively thinking about what MissingH should be for awhile now, and wonder if you all would have some suggestions. First, let me back up and describe a bit of what MissingH is. It gets its name because I think that it has useful functions that are "missing" from the standard Haskell libraries. But I can see how it's not very descriptive. The major features 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 * Assorted list, string, regexp, bit, pointer, etc. utilities * MIME and email parsers. I wrote most of the code myself, but did pull some large chunks from others where licenses were compatible. The API reference is at http://gopher.quux.org:70/devel/missingh/html/index.html So, some of the questions are: Should this all be one library? 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. Should the module naming scheme be changed? 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. Could, and should, any of this be integrated into the Haskell libraries project? (That set of libraries formerly known as fptools) A few bits of code have already found their way into them. But I bet there could be a lot more. Maybe even the majority of it. How could greater community participation be encouraged, while still encouraging quality control? I have received some very good contributions to MissingH from people, and that's been great. I've also received some that just aren't that great -- they don't have Haddock docs, the code is opaque, they don't come with unit tests, etc. But by and large, I've been maintaining it mostly myself. Whenever I write some code, I think about whether this is generic code that could be useful in other projects. If so, I consider whether it would be appropriate for MissingH (and it usually is). It would be wonderful if others would be interested in contributing code that solves some need as well. There is a public darcs repo already, and I have received some darcs patches from people (thanks!) I'm not trying to rid myself of MissingH, but I think that it could be a nice resource for small tools from the entire community, if we can maintain a structure and QA footprint to it. What else should be done to make this a valuable resource for Haskell programmers? And a showcase for what is possible with Haskell? The floor's open... Thanks, -- John