Re: Proposal, Heirarchical module structure for tools

"Neil Mitchell" <[email protected]> wrote:

> The current hattools directory has 38 Haskell files in it, and 34
> .h/.c files. It would be nice if these were split so it was easy to
> determine the files in one program, and what is a tool versus what is
> a library.

In principle, I agree that using the hierarchical namespace to separate
concerns would be nice.

> Hat - global module in which all Hat stuff resides
> (this clashes with the hat-trans output, does this matter?)

Yes, it matters a great deal.  We have reserved the 'Hat' top-level
namespace for the exclusive use of trace-transformed programs.  No-one
should ever use that namespace intentionally for anything else.

My suggestion is to reserve Tracing.Hat as the root of a hierarchy for
Hat-related trace-viewing (or transforming?) libraries.

> Hat.Lib - directory for libraries, which export a nice API for using
> in the tools - for example HatCover as Hat.Lib.Cover.
> 
> Hat.Tool - directory for the tools, for example HatCoverText, as
> Hat.Tool.Cover

I don't like this division much.  How should I decide whether I'm
looking for a Lib or a Tool, or a Common?  In principle, everything can
be treated more or less as a library.  Lib/Tool/Common is a
meta-category, not a name chosen to reflect the underlying
functionality.

My suggestion would be just to drop that part.  So, e.g.

   Tracing.Hat.Observe
   Tracing.Hat.Trail
   Tracing.Hat.SExp
   Tracing.Hat.HighlightStyle

Then, other modules used exclusively by a single "tool" (or style of
interaction I suppose) would be placed directly under the relevant
category, e.g.

   Tracing.Hat.Observe.FileAccess
   Tracing.Hat.Observe.TextUI
   Tracing.Hat.Observe.GUI
   Tracing.Hat.Trail.Navigation

Regards,
    Malcolm