Haddock seems to generate wrong types in newtype deriving
Hi - I have the following code: data MState = MState -- details omitted type MonadStateMState = MonadState MState -- necessary for Haddock newtype ManagerM a = ManagerM (StateT MState IO a) deriving (Monad, MonadIO, MonadStateMState) which means that ManagerM is an instance of Monad, MonadIO, and MonadState MState. However, the Haddock docs look like: data ManagerM a Instances ??? a => Monad (ManagerM a) ??? a => MonadIO (ManagerM a) ??? a => MonadStateMState (ManagerM a) which doesn't seem at all right to me. I'd have thought it should say: data ManagerM a Instances Monad ManagerM MonadIO ManagerM MonadStateMState ManagerM Is this just a bug in Haddock or am I misunderstanding something about Haskell? Thanks, Brian.
Brian Hulley wrote:
Hi - I have the following code:
data MState = MState -- details omitted type MonadStateMState = MonadState MState -- necessary for Haddock newtype ManagerM a = ManagerM (StateT MState IO a) deriving (Monad, MonadIO, MonadStateMState)
which means that ManagerM is an instance of Monad, MonadIO, and MonadState MState. However, the Haddock docs look like:
data ManagerM a Instances ??? a => Monad (ManagerM a) ??? a => MonadIO (ManagerM a) ??? a => MonadStateMState (ManagerM a)
which doesn't seem at all right to me. I'd have thought it should say:
data ManagerM a Instances Monad ManagerM MonadIO ManagerM MonadStateMState ManagerM
Is this just a bug in Haddock or am I misunderstanding something about Haskell?
It's a bug / missing feature in Haddock. Haddock is basically pretty dumb when it comes to understanding Haskell code; it knows about the syntax and the module system, and that's about all. It makes a half-hearted attempt to figure out what instances you get from deriving clauses, but it's not complete, and you've encountered a case it doesn't handle. One day Haddock will be built on top of the GHC API, and all this will be fixed... Cheers, Simon
Simon Marlow wrote:
Brian Hulley wrote:
Hi - I have the following code:
[snip]
Is this just a bug in Haddock or am I misunderstanding something about Haskell?
It's a bug / missing feature in Haddock. Haddock is basically pretty dumb when it comes to understanding Haskell code; it knows about the syntax and the module system, and that's about all. It makes a half-hearted attempt to figure out what instances you get from deriving clauses, but it's not complete, and you've encountered a case it doesn't handle.
One day Haddock will be built on top of the GHC API, and all this will be fixed...
Thanks - I'm glad it's not just me! In the meantime, I found a better workaround (since the type decl using a class name is not legal Haskell) is just to use -cpp to preprocess for both ghc and haddock so that haddock sees explicitly defined dummy instances instead of a newtype deriving clause, then perfect results are obtained... :-) Regards, Brian.
Am Montag, 24. April 2006 14:36 schrieb Brian Hulley:
Thanks - I'm glad it's not just me! In the meantime, I found a better workaround (since the type decl using a class name is not legal Haskell) is just to use -cpp to preprocess for both ghc and haddock so that haddock sees explicitly defined dummy instances instead of a newtype deriving clause, then perfect results are obtained...
This workaround is actually "state-of-the-art"! :-P If you look at the hierarchical libraries, there is often code like: data VertexArrayDescriptor a = VertexArrayDescriptor !NumComponents !DataType !Stride !(Ptr a) #ifdef __HADDOCK__ -- Help Haddock a bit, because it doesn't do any instance inference. instance Eq (VertexArrayDescriptor a) instance Ord (VertexArrayDescriptor a) instance Show (VertexArrayDescriptor a) #else deriving ( Eq, Ord, Show ) #endif Cheers, S.
participants (3)
-
Brian Hulley -
Simon Marlow -
Sven Panne