Export lists in modules

[Jean-Philippe Bernardy]

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.

Cheers,
JP.

On 2/23/06, Simon Marlow <simonmar at microsoft.com> wrote:
> On 22 February 2006 17:27, Malcolm Wallace wrote:
>
> > However, I would be
> > equally happy to combine type/newtype/data into a single keyword for
> > exports.
>
> for the record, I am in favour of tagging export specifiers with 'class'
> or 'type' (using 'type' for all type constructors, in light of yours and
> John's points).
>
> I'm not in favour of adding type signatures to export lists.  It's a
> half way solution to specifying interfaces, and I'd rather design it
> properly from scratch.  If modules are to contain interfaces, I don't
> think extending the export list is the way to do it.  I'd rather do
> something like:
>
> --------------------------------------
> modules M exports
>
> class Eq a where
>  (==) :: a -> a -> Bool
>
> data T :: * -> *
> f :: T -> Int
> mkT :: Int -> T
>
> where -- implementation below here
>
> data T a = C a Int
> f = ...
> --------------------------------------
>
> Not a proposal by any means, and I don't think that Haskell' should
> tackle this, but this seems the right direction to me.
>
> Cheers,
>        Simon
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime at haskell.org
> http://haskell.org/mailman/listinfo/haskell-prime
>