haddock

haddock copied to clipboard

In the following snippet from the docs for Data.Functor.Rep I wonder why haddock shows only the kind of the associated Rep type:

Wouldn't it be better to see type Rep (Identity :: * -> *) = () instead?

Yes, this is probably a good idea!

The same problem shows up for associated data families.

@harpocrates Do we have this data from what Haddock parses or does it need a deeper addition to what it can do? In other terms, is that a displaying issue, or a parsing issue?

@harpocrates Do we have this data from what Haddock parses or does it need a deeper addition to what it can do? In other terms, is that a displaying issue, or a parsing issue?

This is a deeper addition, but not a parsing/display issue. The information we need is available within GHC already, but Haddock would need to figure out how to extract it properly. Right now, the only bit of information we collect about class instances is the instance head (we figure out instance signatures later by substitution, using the instance head variables).

Querying the right type/data family instance might be tricky too - especially since there might just not be any instance (if, for instance, the type/data was omitted from the instance)!

(An updated screenshot FWIW ^)

I agree that type family instances really ought to be in the haddocks. You can't understand any API that makes use of type families without clicking through to the source.

@jberryman This looks great. :)

@Kleidukos this is just the current hackage haddock style (but I agree it looks pretty nice :). One would like to see e.g.

type Uninterned InternedString = String

Just seeing type Uninterned InternedString isn't helpful