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
are
separated from the implementation, or are duplicated with the
implementation. Code is less "agile".
- more complication in the language definition and compiler
Cheers,
Simon
More information about the Haskell-prime
mailing list