On Thu, 1 Jan 2004 21:07:00 -0500 ajb@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.