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