Proposal: module namespaces.

[Frank Atanassow]

I have two nitpicking comments.

Malcolm Wallace wrote (on 26-02-01 17:59 +0000):
>   * The use of qualified imports becomes more verbose: for instance
>             import qualified XmlParse
>                       ... XmlParse.element f ...
>     becomes
>             import qualified Text.Xml.Parse
>                       ... Text.Xml.Parse.element f ...
>     However, I propose that every import have an implicit "as"
>     clause to use as an abbreviation, so in
>             import qualified Text.Xml.Parse   [ as Parse ]
>     the clause "as Parse" would be implicit, unless overridden by the 
>     programmer with her own "as" clause.  The implicit "as" clause
>     always uses the final subdivision of the module name.  So for
>     instance, either the fully-qualified or abbreviated-qualified names
>             Text.Xml.Parse.element
>             Parse.element
>     would be accepted and have the same referent, but a partial
>     qualification like
>             Xml.Parse.element
>     would not be accepted.

I don't like the implicit "as". The reason for having a tree structure for
names is that leaves are likely to collide. So I might use both
Text.ParserCombinators.UU and Text.PrettyPrinter.UU. In this case I might want
to use the declarations:

  import qualified Text.ParserCombinators.UU as PC
  import qualified Text.PrettyPrinter.UU as PP

Since a person is likely to use several packages in the same subtree quite
often, and in our goal of a "library-rich world" we expect a plethora of
implementations from disparate sources, I wonder whether the default "as" is
useful enough in practice. As an example, in cases where sibling modules
actually have the same interface and you want to write a client module which
can use either implementation interchangeably, you would always use an
explicit "as" anyway, since you want to write, say, "Tree.map" rather than
"AVL.map" or "RedBlack.map".

Besides, it is only a few more characters to make it explicit, and I think it
is better to avoid implicit behavior when possible.

Well, I don't care too much.

I care more about:

> A fuller proposed layout appears on the web at
>     http://www.cs.york.ac.uk/fp/libraries/layout.html

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

Personally, I prefer the first group being normalized to uppercase rather
than vice versa, since "JPEG" and "HTML" look right, but "Url" and "Odbc" look
terribly wrong. (Unless you are Dutch, in which case maybe "Ui" looks good but
is still misleading. :)

Other miscellanea:

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

  * 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.

  * 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.)

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

  * 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.

-- 
Frank Atanassow, Information & Computing Sciences, Utrecht University
Padualaan 14, PO Box 80.089, 3508 TB Utrecht, Netherlands
Tel +31 (030) 253-3261 Fax +31 (030) 251-379