[Haskell-cafe] The Future of MissingH

[Malcolm Wallace]

John Goerzen <jgoerzen at complete.org> wrote:

> 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