On Thu, 1 Jan 2004 21:07:00 -0500 [EMAIL PROTECTED] 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. _______________________________________________ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
