Turn on -fdefer-type-errors or use the 7.8 beta with type holes. Write your types first. Write whole programs in the style of

   lalala :: f g Int -> m q -> z ()
   lalala = undefined

and then just check and see if your logic holds water. Then, slowly fill in the implementations and use -XImplicitParams and ?f or 7.8 type holes and _ as placeholders that GHC will tell you the goal types of.

Reflect as much information about side effects into your types as possible. Write new typeclasses to encapsulate smaller APIs like

    class Teletype m where
      writeLine :: String -> m ()
      readLine  :: m String

    instance Teletype IO where
      writeLine = putStrLn
      readLine  = getLine

    echo :: Teletype m => m r
    echo = forever $ readLine >>= writeLine

Then now we know what subset of IO `echo` actually uses.

Generally, the type system is your friend and used correctly it lets you write a shitty first draft of your program elegantly and quickly and then get to the hard part of typing it out later.

If you're talking about getting it to compile...

If foo is giving you problems, write it as

   foo :: (the type you think it should have)
   foo = undefined

If it compiles you at least know your type is right. Then, leaving the type annotation in place, replace undefined with a more useful expression. (Soon we will all be using Type Holes instead of this trick.)

I like hdevtools for mark-errors-on-save. I don't know if there's an emacs hook for it, but it's emacs so probably.

If you're talking about debugging after it compiles... I'm still working on that. I spent part of this past weekend digging into QuickCheck.

I can recommend VIM with Syntastic[0] and vim2hs[1]. You'd probably also want Vundle to manage plugins though.

What I get from that is my code is checked for style/compile errors everytime I save with ghc-mod and hlint. There's also commands to output the type of a function, run haskell code in VIM etc.

Note that you need ghc-mod installed for syntastic to take effect though.

[0] https://github.com/scrooloose/syntastic [1] https://github.com/dag/vim2hs

You should study Haskell types. Debugging anything in Haskell without a basic understanding of the type system is daunting.

Additionally, Yesod relies heavily on quasiquoting and template haskell which can lead to some very cryptic code and errors. I generally prefer Snap for this reason and many others.

I find I spend most of my time on the engineering than in understanding types. (I recommend 'Types and Programming Languages by Pierce for general type stuff and Typeclassopedia for Haskell specific). Though I confess Yesod is the first real time I've seen quasiquoting and template haskell before. I haven't yet got a familiarity of what certain errors mean. 50% of the time when I get a compile error, the error message seems to be off on a complete tangent and is nowhere near where the actual error was.

Eg. I had some problem where a Data.Text was being passed into a function where Data.Text.Lazy was expected (Network.Mail.Mime.simpleMail for the record). The error message was deep in the internals of Data.Text.Lazy rather than in my code. I had to play a ridiculous pecking game of using undefine on each time I use Data.Text in turn in order to find which particular Data.Text was causing the error and then explicitly force one particular argument type to be a Data.Text.Lazy. I didn't feel like the compiler helped me at all.

Stepping through a program linearly doesn't seem possible (though not entirely sure why not) so I have no intermediate or step through capability. I also can't (normally) just stick in a println in the middle of a function or view the data structures at any particular point of the program. These are two tools I use all the time with Java and C#, but in Haskell I am rendered blind.

http://hackage.haskell.org/package/base-4.6.0.1/docs/Debug-T... is what you want to use for emitting debug text or debug data dumps.

Look into Debug.Trace for old-school println debugging.

try hdevtools plugin for your editor.