Perspectives on learning and using Haskell

[Derek Elkins]

On Thu,  1 Jan 2004 21:07:00 -0500
ajb at spamcop.net wrote:

> > (6) I have found that Haskell seems to a particularly effective
> > platform for pursuing some ideas of extreme programming,
> 
> There you go. :-)
> 
> There is only one problem I've found with test-driven development in
> Haskell.  In C++, it's possible to break the "module" abstraction
> (yes, I know, C++ doesn't have modules; it has classes, which are
> really instantiable modules) by using "friend".  In Haskell, I find
> myself occasionally having to expose parts of a module which I would
> prefer not to, in order for the unit tests suite to do their job
> effectively.
> 
> I wonder if there might be a way to fix this, say, by allowing modules
> to selectively expose parts of their interface depending on who wants
> to use it.

Well, the quick and dirty solution (at least with GHC) is to use GHCi
and interpret the modules, which should keep some internals readily
accessible.  For example, I use the new -e option of GHC to run my unit
tests.

The "nicer" way*, though it could use less typing and "extraneous"
files, is simply use multiple modules.

module FooInternals where

publicFoo :: Foo -> Bar
publicFoo x = privateFrob x

privateFrob x :: Foo -> Bar
privateFrob x = ...

debugFoo :: (Foo -> Bar) -> Foo -> Bar
debugFoo f x = ...

module Foo ( publicFoo ) where
import FooInternals

module FooDebug ( publicFoo, debugFoo ) where
import FooInternals

* Okay, so it doesn't really solve the "problem", it's just a way of
structuring that avoids it.