Proposal: module namespaces.

[Malcolm Wallace]

Frank writes:
> I wish we could agree on capitalization of acronyms. On one hand, we have:
>     Gtk, Jpeg, Html, Xml
> but on the other:
>     AVL, ODBC, FIFO, MD5, UI, PPM, FFI, IO, UU, PP, DSP, FFT, FIR, URL, CGI

Hmm, yes.  Actually, my preferred solution would be to use acronyms
only when they are extremely well known, and otherwise to spell things
out in full.  So
      Gtk, Jpeg, Html, Xml, Fifo, UI, Ppm, IO, URL, CGI
but
      ObjectDataBase, Foreign, Utrecht, PrettyPrint, SignalProcessing,
      FourierTransform, GroeltzmanFilter ...

But these things are inevitably a matter of taste.  Some people detest
the MixedUpperAndLower style.

>   I think the top-level "Interface" is better named "Console", to contrast
>   with "Graphics".

Cool.  I like it.

>   I would prefer short names to long. So: "Text.Parse" rather than
>   "Text.ParserCombinators", "Data.Struct" rather than "Data.Structures",
>   "Graphics.Draw" rather than "Graphics.Drawing", etc. Generally, the
>   ancestors of a short name should give enough context to disambiguate it.

In terms of software engineering, I think fully descriptive names
are better than abbreviations.  On the other hand, no-one likes names
that are long just for the sake of completeness.

  * Text.Parse could be ambiguous - does it contain combinator
    libraries, or support libraries for Happy?  Or maybe: Text.Parser
    - does it indeed parse text according to some syntax/grammar,
    or does it just contain functions that help you to parse text?
    Text.ParserCombinators is at least clear.

  * Graphics.Draw might indeed be better than Graphics.Drawing

  * Data.Struct - I don't like it - it sounds like C!

>   I would move "Format" out of "Graphics" and into "Data.Encoding". (But
>   maybe "Encoding" is intended to be a collection of things of `universal'
>   encodings, which clearly "Jpeg", for example, is not.)

Indeed, we do need to guard against overlapping categories.  I don't
know about this particular case - Graphics.Format seems more natural to
me.  As you say, it contains datatype-specific codecs, not universal ones.

>   Change "Data.Structures.Trees" and "...Graphs" from plural to
>   singular. Same for "Data.Encoding.Bits". But not "Data" to "Datum"! :)

Like Data.Structure.Tree etc?  Yes, looks ok.

Data.Encoding.Bits is a special case.  There are two current bit
libraries, one called Bit (in nhc98), the other called Bits (in ghc).
They even have different interfaces.  Sadly, inconsistencies like this
have grown up over the years.  But I think we can turn the situation
into a more positive one by permitting the distribution of competing
libraries - just like for pretty-printers, we can extend the namespace
to have both:

    Data.Encoding.Bit.Glasgow
    Data.Encoding.Bit.York

Mechanism, not policy.

>   Maybe change "Data.Structures" and "Data.Encoding" to one name each,
>   "DataStruct" and "DataEncoding" (or "Encoding" or "Codec"). The reason is
>   that it's not clear to me why they belong in the same subtree except for
>   the fact that in English both terms start with "Data". In other words, we
>   should try to group things semantically rather than lexically.

I quite like the name Codec.  MD5 is not a codec as such - more of
a checksum really.  For me, data structures and data codecs belong
semantically in the same subtree - it isn't just a lexical grouping.

Thanks for your suggestions!
Regards,
    Malcolm