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