Haddock strings in .hi files

[Edward Kmett]

On Fri, Mar 21, 2014 at 7:38 AM, Simon Marlow <marlowsd at gmail.com> wrote:

> Ok, I buy the argument that if we're already compiling everything, we
> shouldn't have to re-typecheck it all in Haddock. Of course if you're *not*
> already compiling everything, then the argument doesn't apply: Haddock does
> support generating documentation from source files without precompiling
> them, but I think if you ask the GHC API to load modules with -fno-code it
> should do the right thing: load up the .hi files if they're up to date, or
> typecheck the modules otherwise.
>

Definitely. That said, cabal installing a package with documentation is by
far the most common scenario, and that is the thing that could be sped up
the most here.

So I think having GHC spit out the docs as a side-effect of compilation is
> fine, so long as we don't have to do all the Haddock processing inside GHC
> itself, and provided this eliminates Haddock's own interface files (which
> are a pain).  If the docs go in the .hi file, then they must go in a
> separate section that is lazy parsed - we already do this for various other
> sections in the .hi file.
>

Exactly.


> I don't think this is easy, but it's probably doable.  The code that
> attached docs to declarations is currently part of Haddock itself, so
> perhaps this has to move into GHC.
>

This was originally scoped to be around the level of work of a GSoC
project, and folks were worried that it came in a bit light, so it taking
some effort isn't unreasonable. I don't think we have an application for it
yet this year, so we probably have some time to chew it over unless someone
applies to do this in the next few hours. (We had one student, but she
backed out at the last second due to other constraints.)

-Edward
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140321/2a49aa79/attachment.html>