mouseover types via hscolour, haddock, cabal

[David Waern]

2011/6/6 Ranjit Jhala <jhala at cs.ucsd.edu>:
>
> Yes, I did know that. The difference is that here you have
> the types for _every_ identifier that occurs in a program,
> not just the top-level bindings that the hoogle database
> contains. This allows HsColour to display the type of any
> arbitrary identifier if one puts the mouse over the
> occurrence of the identifier in the HTML text.
>
> Right now, one could "simulate" this by entering the name
> of the identifier into Hoogle and getting the type out, but
> this (tedious) process only works for the subset of identifiers
> indexed by hoogle.

Ah, good point.

>> About the dependency, I don't think we can depend on syb as it's not a
>> GHC boot library. (Haddock is used in the GHC build process and can
>> only depend on boot libraries). syb was moved out of the boot
>> libraries a while ago, unfortunately.
>
> Ah! I had imagined since the various types in GHC were all
> instances of Data and Typeable, that GHC would depend on syb.
> Do you know if there is some other generic library that GHC
> depends on? If not, it may be easiest to have Haddock call "Annot"
> as a separate binary (as it does HsColour...)

Data and Typeable are defined separately from syb, syb just uses them.
GHC currently doesn't use any generics library. I suppose we could
start a discussion about which generics library GHC and Haddock should
use. I don't think it necessarily needs to be syb, but one thing is
sure - it would be very convenient to have one.

About the output: I noticed that in the HTML some of the names point
to the wrong type, e.g Interface points to ifaceRnDocMap. Also some of
the types look quite "raw" and could be simpler, e.g. the type of
Monad. And many of the names don't have tool-tips at all. Are these
part of the improvements you plan to make? Just making sure we don't
miss something.

I'm happy to include the Annot backend if we solve the syb issue.
However you should know that the long term plan is to make the
backends stand-alone programs. The idea is that Haddock should produce
one single file containing everything useful that it knows about the
package.

David