[Haskell-cafe] The Future of MissingH

[John Goerzen]

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