Haddock strings in .hi files

[Mateusz Kowalczyk]

On 20/03/14 10:45, Herbert Valerio Riedel wrote:
> On 2014-03-20 at 11:39:47 +0100, Mateusz Kowalczyk wrote:
>> [...] the functionality to grab documentation for something can be
>> provided by Haddock and GHCi then can use that. I think an extra
>> benefit of this is that we get to decide in Haddock how we present
>> such documentation: we can have different pretty printers if we so
>> desire. If the strings are in .hi files themselves, the only choice is
>> to show them verbatim which can be sub-par.
>>
>> So if having documentation in GHCi is the sole goal, I think it's not
>> worth putting the strings in the .hi file.
> 
> Just wondering: how would GHCi have to handle the case of e.g. ':reload'
> (in "-fobject-code" as well as "-fbyte-code" mode), in order to have
> access to up-to-date Haddock strings?
> 
	
I imagine it can't if I'm guessing what you mean properly. If we are to
use Haddock, you'd have to generate up-to-date .haddock files. I don't
think that's a big problem because you wouldn't be asking for docs of
things that you're changing: you can just look in the source for that if
you really need to. I think the main utility of such feature is being
able to ask about docs of the libraries which we use (which we don't
change on the fly and have the docs for).

Well, it can, using its own API (just like we use it in Haddock) but I
don't imagine that would be fast enough for the user. I don't know, I'd
have to experiment.

-- 
Mateusz K.