<div dir="ltr"><div>Hey Matt,</div><div><br></div><div>In principle, there should be no problem interacting with source plugins, or implementing this as a source plugin, given that the generating function has type:</div><div><br></div><div>enrichHie :: GhcMonad m => TypecheckedSource -> RenamedSource -> m (HieAST Type)</div><div><br></div><div>The only reason the GhcMonad constraint is necessary and this is not a pure function is because desugarExpr has type</div><div>
</div><div><pre><a name="line-257"></a><a name="deSugarExpr"></a><span class="gmail-hs-definition">deSugarExpr</span> <span class="gmail-hs-keyglyph">::</span> <span class="gmail-hs-conid">HscEnv</span> <span class="gmail-hs-keyglyph">-></span> <span class="gmail-hs-conid">LHsExpr</span> <span class="gmail-hs-conid">GhcTc</span> <span class="gmail-hs-keyglyph">-></span> <span class="gmail-hs-conid">IO</span> <span class="gmail-hs-layout">(</span><span class="gmail-hs-conid">Messages</span><span class="gmail-hs-layout">,</span> <span class="gmail-hs-conid">Maybe</span> <span class="gmail-hs-conid">CoreExpr</span><span class="gmail-hs-layout">)<br></span></pre>So we need a GhcMonad to get the HscEnv. We need to desugar expressions to get their Type.</div><div><br></div><div>However, in a private email with<span style="font-weight:normal"><span name="Németh Boldizsár" class="gmail-gD"> Németh Boldizsár</span></span> regarding implementing this as a source plugin, I had the following concerns:</div><div><br></div><div><div>1. Since HIE files are going to be used for haddock 
generation, and haddock is a pretty important part of the haskell 
ecosystem, GHC should be able to produce them by default without needing
 to install anything else.<br></div><div>2. Integrating HIE file 
generation into GHC itself will push the burden of maintaining support 
to whoever makes breaking changes to GHC, instead of whoever ends up 
maintaining the source plugin. This way, HIE files can be a first class 
citizen and evolve with GHC.<br></div><div>3. Concerns about portability of source plugins - it should work at least wherever haddock can currently work<br></div><div>4.
 I believe there are some issues with how plugins interact with GHCs 
recompilation avoidance? Given that HIE files are also meant to be used 
for interactive usage via haskell-ide-engine, this is a pretty big deal 
breaker.</div></div><div><br></div><div>I understand (4) has been solved now, but the first three still remain.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 26 June 2018 at 16:23, Matthew Pickering <span dir="ltr"><<a href="mailto:matthewtpickering@gmail.com" target="_blank">matthewtpickering@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Have you considered how this feature interacts with source plugins?<br>
<br>
Could the generation of these files be implemented as a source plugin?<br>
That would mean that development of the feature would not be coupled<br>
to GHC releases.<br>
<br>
Cheers,<br>
<br>
Matt<br>
<div><div class="h5"><br>
On Tue, Jun 26, 2018 at 11:48 AM, Zubin Duggal <<a href="mailto:zubin.duggal@gmail.com">zubin.duggal@gmail.com</a>> wrote:<br>
> Hello all,<br>
><br>
> I've been working on the HIE File<br>
> (<a href="https://ghc.haskell.org/trac/ghc/wiki/HIEFiles" rel="noreferrer" target="_blank">https://ghc.haskell.org/trac/<wbr>ghc/wiki/HIEFiles</a>) GSOC project,<br>
><br>
> The design of the data structure as well as the traversal of GHCs ASTs to<br>
> collect all the relevant info is mostly complete.<br>
><br>
> We traverse the Renamed and Typechecked AST to collect the following info<br>
> about each SrcSpan<br>
><br>
> 1) Its type, if it corresponds to a binding, pattern or expression<br>
> 2) Details about any tokens in the original source corresponding to this<br>
> span(keywords, symbols, etc.)<br>
> 3) The set of Constructor/Type pairs that correspond to this span in the GHC<br>
> AST<br>
> 4) Details about all the identifiers that occur at this SrcSpan<br>
><br>
> For each occurrence of an identifier(Name or ModuleName), we store its<br>
> type(if it has one), and classify it as one of the following based on how it<br>
> occurs:<br>
><br>
> 1) Use<br>
> 2) Import/Export<br>
> 3) Pattern Binding, along with the scope of the binding, and the span of the<br>
> entire binding location(including the RHS) if it occurs as part of a top<br>
> level declaration, do binding or let/where binding<br>
> 4) Value Binding, along with whether it is an instance binding or not, its<br>
> scope, and the span of its entire binding site, including the RHS<br>
> 5) Type Declaration (class or regular) (foo :: ...)<br>
> 6) Declaration(class, type, instance, data, type family etc.)<br>
> 7) Type variable binding, along with its scope(which takes into account<br>
> ScopedTypeVariables)<br>
><br>
> I have updated the wiki page with more details about the Scopes associated<br>
> with bindings:<br>
> <a href="https://ghc.haskell.org/trac/ghc/wiki/HIEFiles#Scopeinformationaboutsymbols" rel="noreferrer" target="_blank">https://ghc.haskell.org/trac/<wbr>ghc/wiki/HIEFiles#<wbr>Scopeinformationaboutsymbols</a><br>
><br>
> These annotated SrcSpans are then arranged into a interval/rose tree to aid<br>
> lookups.<br>
><br>
> We assume that no SrcSpans ever partially overlap, for any two SrcSpans that<br>
> occur in the Renamed/Typechecked ASTs, either they are equal, disjoint, or<br>
> strictly contained in each other. This assumption has mostly held out so far<br>
> while testing on the entire ghc:HEAD tree, other than one case where the<br>
> typechecker strips out parenthesis in the original source, which has been<br>
> patched(see <a href="https://ghc.haskell.org/trac/ghc/ticket/15242" rel="noreferrer" target="_blank">https://ghc.haskell.org/trac/<wbr>ghc/ticket/15242</a>).<br>
><br>
> I have also written functions that lookup the binding site(including RHS)<br>
> and scope of an identifier from the tree. Testing these functions on the<br>
> ghc:HEAD tree, it succeeds in looking up scopes for almost all symbol<br>
> occurrences in all source files, and I've also verified that the calculated<br>
> scope always contains all the occurrences of the symbol. The few cases where<br>
> this check fails is where the SrcSpans have been mangled by CPP(see<br>
> <a href="https://ghc.haskell.org/trac/ghc/ticket/15279" rel="noreferrer" target="_blank">https://ghc.haskell.org/trac/<wbr>ghc/ticket/15279</a>).<br>
><br>
> The code for this currently lives here:<br>
> <a href="https://github.com/haskell/haddock/compare/ghc-head...wz1000:hiefile-2" rel="noreferrer" target="_blank">https://github.com/haskell/<wbr>haddock/compare/ghc-head...<wbr>wz1000:hiefile-2</a><br>
><br>
> Moving forward, the plan for the rest of the summer is<br>
><br>
> 1) Move this into the GHC tree and add a flag that controls generating this<br>
> 2) Write serializers and deserializers for this info<br>
> 3) Teach the GHC PackageDb about .hie files<br>
> 4) Rewrite haddocks --hyperlinked-source to use .hie files.<br>
><br>
</div></div>> ______________________________<wbr>_________________<br>
> ghc-devs mailing list<br>
> <a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/ghc-devs</a><br>
><br>
</blockquote></div><br></div></div>