From: "Claus Reinke"
let's go through 5.2 "Export Lists" to see what would be missing
if we tried to replace the export list with a separation of a module
into a public (exported) and a private (local) part:
any other issues I missed here?
I feel unkeen.
One of the nice things about Haskell is that definitions can appear in any
order. That makes it possible to gather a group of logically related
definitions together, within a module. With your proposal, exported
definitions and non-exported ones would have to be separated.
What would that mean in practice? Suppose I have a few exported functions
and a collection of auxiliary functions that are used to implement them. I
have two choices: either I put the exported definitions in the public
section, and the remaining ones elsewhere in the private section, or I put
everything in the private section with appropriate redeclarations in the
public part -- exportedName = localExportedName or whatever. The first
alternative has the disadvantages that logically related code is separated,
and that the public section of the module may itself become quite large
(since it contains full function definitions), making it hard to see at a
glance what the exported names are. The second alternative has the
disadvantage of introducing an indirection---finding the actual definition
of an exported function becomes more difficult, because one must both scan
the module for it, and first look up the public section to see what the
private version is called. Neither alternative feels really attractive to
Today's export lists at least have the advantage that it is easy to see
what is exported, even if changing the status of a definition from private
to public is a little awkward (with edits in two places). With a tool like
Haddock installed too, once gets a pretty good view of the
interface---arguably better than one can get from a public module section.
Perhaps, given that Haddock is available, a public modifier makes more
sense than an explicit export list---although code browsing would then
require running Haddock during development much more often than today, and
potentially on syntactically incorrect or ill-typed modules.
Incidentally, the Erlang equivalent of Haddock, edoc, is distributed with
the compiler, so that all Erlang installations include the tool, no matter
what platform they're running on. Surely that's a prerequisite for adapting
the language design on the assumption that tools of various kinds are