Haskell-prime Digest, Vol 2, Issue 58

[Sebastian Sylvan]

On 2/24/06, John Hughes <rjmh at cs.chalmers.se> wrote:
>     From: "Claus Reinke" <claus.reinke at talk21.com>
>
>     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 me.
>
> 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 available?
>
> John
>
>
>

Just a quick thought. How about having separating the code in two
sections, public and local, BUT allowing you to export local names by
simply mentioning them in the public section. So the equivalent of
what we have now would be to write all your code in the private/local
section, and then put the names of the functions you want exported in
the public section.
These "exported locals" could be in a separate list like it is now (in
addition to the public section) or it could be enough to just put them
in the public top level like so

------------------
public:
foo = blah + bar

bar -- this re-exports a local bar defined in the private section

A(B,D) -- re-exports data type A with constructors B and D (but keeps C hidden)

baz = blahglah

private:
bar = blahblah
data A = B  | C | D
------------------

Maybe some keyword to re-export local definitions is a good idea. Like
"export bar" or something...

This means you can still group locally related functions together, but
you're allowed to write defintions in the public part of the module as
well. So you get all your public stuff in the same place (good), while
the definitions for some of those items may be in the local area if
that makes sense (good). And there's no extra indirection since the
public name isn't different from the priveate one (good). You do have
to type the name twice, but that's no different from what we have now
(and better, since it's "pay as you go" - you only need to retype
names if you choose to put the definition in the local part).

A likely coding practice would be to put short and simply defitions in
the public interface, but using the exporting feature for larger
functions (which need a significant amount of local helper functions
etc.).

/S

--
Sebastian Sylvan
+46(0)736-818655
UIN: 44640862