On Thu, 2007-08-02 at 13:58 +0100, Alistair Bayley wrote:
and the offending lines in this file are:
#ifndef __HADDOCK__ deriving (Functor, Monad, MonadIO, MonadFix, MonadReader sess) #else -- Haddock can't cope with the "MonadReader sess" instance deriving (Functor, Monad, MonadIO, MonadFix) #endif
so it would appear that __HADDOCK__ is not defined.
Sorry, I should have said, "so it appears that -cpp is not being used".
It uses -cpp if CPP is in the language extensions in the .cabal file. (At least that's what the code says it's supposed to be doing which is not a guarantee that it works). It does also define __HADDOCK__ when it uses cpp. Hmm, actually there is a problem here. Unlitting does indeed remove all the literate comments, so haddock will never see any markup that is put in the non-code part. To work with current haddock it'd have to be:
-- | This is a haddock comment foo = ...
because that's the only code haddock will see since unlitting turns a literate haskell file into a valid .hs file. It's a purely textual transformation and it's done by removing all the non > lines. Perhaps unlitting should be done by converting all literate comments into {- ... -} style comments. Then it'd probably work with haddock like you have it now: | haddock comment
foo = ...
since that'd become: {- | haddock comment -} foo = ... Or something like that. Perhaps that's worth investigating and adding to ghc/cpphs or Cabal's own existing pure Haskell impl of unlitting. Duncan