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