HIE Files

Simon Peyton Jones simonpj at microsoft.com
Tue May 15 08:42:44 UTC 2018

|  > Why not put the .hie-file info into the .hi file?  (Optionally, of
|  > course.)
|  >
|  Simon, I'm curious what benefits you think we might get from this?
|  (I'm one of the mentors on this GSoC project btw).

Well, I've always thought that we should really put the .hi file into the .o file!  Having two files risks getting things out of sync, and three makes that worse.  The file is just a place to keep a blob of info.  What's the motivation for having two .hie as well as .hi?

|  > What tools/libraries do you plan to produce to allow clients to read
|  a .hie file and make send of the contents?
|  For GSoC as a proof of concept the idea is to teach haddock's
|  hyperlinked-source backend to use this information to add type-
|  annotation-on-hover to the colorized, hyperlinked, html source.

That's great.  But would it not be good to offer a library, with a well-defined API, that allows a client (including Haddock) to parse those .hie files into syntax trees or whatever?  You'll need to do that to allow the haddock thing you describe -- and it'd be much better to make the parser (and doubtless lots of utility function like finding things in the tree) available to any client not just haddock.

And that in turn raises the questions of WHAT syntax tree.  HsSyn?  Template Haskell?  Haskell-src-exts?  Or something new?   Shayan and Alan are busy parameterising HsSyn to make it non-GHC-specific, and directly usable for this kind of endeavour ("Trees that grow").  It'd be great to build on their work.

|  with the GHC API. (This by the way is one of the key benefits of
|  keeping the file separate from standard hi files -- it should be
|  parseable and consumable without needing to link in GHC).

Yes, not linking in GHC is a reasonable goal; but having two files and file formats is not a necessary consequence of that goal.  Nothing stops us making a library to parse .hi files -- indeed the entire iface/ directory in GHC is quite well separated for that precise purpose.

None of this is to criticise the plan.  I think it's a great idea to make more info more readily available to more tools.   I'm just poking at it a bit 😊.


More information about the ghc-devs mailing list