Export lists in modules

Simon Marlow simonmar at microsoft.com
Thu Feb 23 06:12:39 EST 2006

On 23 February 2006 10:28, Jean-Philippe Bernardy wrote:

> I lost track of what is the issue being tackled here. What's broken
> with the current way of specifying exported entities? Imho it's the
> best system that I've seen (across all languages I know).
> A lot of language chose to separate interface from implementation in
> source files. (eg. Ada)  I find this annoying because to change a
> single thing you have very often to edit two files. The
> counter-argument is that the user of a module wants to see only the
> interface. However, with modern tools like haddock, one doesn't look
> at the source code any more to understand the interface of a module,
> but some specifically processed version of the sources, so this
> argument is void. So, again, please keep implemenation and interface
> as close as possible.
> Public modifiers permit this adequately, but they don't fit with
> haskell syntax style very well.
> The current export list being 1. very light 2. optional and 3.
> allowing to re-order presentation in haddock (or such a similar tool)
> makes it the very best solution for haskell, imho.

I certainly sympathise with this point of view.  It's a difficult call,
there are good arguments on both sides.

For interfaces:

  - separately declaring interfaces is generally considered good 
    software engineering; stops you accidentally changing the interface

  - having an interface in the source code makes browsing the code
    that much easier

  - replaces the export list

  - makes mutually recursive modules easier to implement (maybe)

Against interfaces:

  - good tool support lets you browse interfaces anyway, and could tell
    you when you break an existing interface

  - makes life harder for the implementer: interface and documentation
    separated from the implementation, or are duplicated with the
    implementation.  Code is less "agile".

  - more complication in the language definition and compiler


More information about the Haskell-prime mailing list