I have used the ghci debugger but would really prefer if it was somewhat integrated with a text editor to simplify the process of setting breakpoints. It should probably not strictly evaluate every visible variable but at least simplify the process of looking at the local state.
I recently found the trace function which has been helpful by allowing debug printouts from otherwise hard places.
Yes, a frontend for the GHCi debugger would be a good thing. Maybe we'll get something done during the next Hackathon. However, in the mean time:
Alternatively, Haskell lends itself nicely to bottom-up testing using QuickCheck. I.e., test your components individually, then put them together. If your code is pure this often Just Works.
A good way to debug Haskell code is to write and test algebraic laws using QuickCheck and SmallCheck. There have been several Haskell debuggers including Hat, Hood, and Freya, but none of them have been perceived as sufficiently valuable to be worth maintaining for a long time.
When it's Haskell, you have to think differently about how to do things. The ICFP paper on the QuickCheck page has some good examples to get you started. If you want a real-world example xmonad is extensively debugged using QuickCheck.
As a side note, be aware that Debug.trace will NOT be your friend when debugging multithreaded programs.
Testing is the way to go in the long run.
For my own purposes I find that it's a combination of factors.
As seen in other answers, a lot of people love QuickCheck. I've found it difficult to define meaningful QuickCheck test cases for at least some of my code so generally make more use of standard unit tests. That being said, there's an excellent introduction to using QuickCheck in Chapter 11 of Real World Haskell.
Should you find yourself using both QuickCheck and HUnit, you may want to look into test-framework.