[Haskell-cafe] Unexported functions are evil

[David Roundy]

On Sun, May 15, 2005 at 12:29:11PM +0200, Peter Simons wrote:
> The only reason I could think of is that a function is considered to be
> "internal", meaning: You don't want users of the module to rely on the
> function still being there (or still working the same way) in any of the
> next revisions.

To me, this is a sufficient reason.  The art of programming is the art of
creating interfaces, and my feeling is that modules should export as little
as possible, and every function exported should be carefully considered.

> On those occasions, however, why not put the function into a module, say
> "Foo.Bar.Private" and import it into "Foo.Bar" from there? Then those
> people who enjoy playing with fire _can_ use it, and everybody else will
> not.

Because a separate module is more work.  Almost every module I write has
private functions, and I'd really not want to write twice as many modules.
In darcs, if someone needs to "play with fire", he can do it right there in
the module itself, and export a new interface function.

But I guess perhaps you're thinking about "library" style modules? In the
case of darcs, I'd say that the whole point of using modules (besides
making things faster to compile) is to place these barriers, so that one
can modify an individual module without worrying about the rest of the
code, as long as one keeps the interface fixed.

There's also the ease of bug-writing issue.  I think that exported
interfaces should be the sorts of functions where the meaning of the
function can be guessed from its name and type.  If you need to read the
code of a function just to see what it does, you should be modifying the
module rather than importing a function from it.
-- 
David Roundy
http://www.darcs.net