<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap:break-word;line-break:after-white-space"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">Another reason that this probably should go into the mainline rather than a plugin is that Zubin was explaining to me that the mechanisms introduced could improve and generalize the “:set +c” family of type and location information provided by ghci: <a href="https://downloads.haskell.org/~ghc/master/users-guide/ghci.html#ghci-cmd-:set%20+c">https://downloads.haskell.org/~ghc/master/users-guide/ghci.html#ghci-cmd-:set%20+c</a></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">—g</div> <br> <div id="bloop_sign_1530064738369624064" class="bloop_sign"></div> <br><p class="airmail_on">On June 26, 2018 at 7:09:23 AM, Zubin Duggal (<a href="mailto:zubin.duggal@gmail.com">zubin.duggal@gmail.com</a>) wrote:</p> <blockquote type="cite" class="clean_bq"><span><div><div></div><div>
<title></title>
<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>
<pre><a name="line-257" id="line-257"></a><a name="deSugarExpr" id="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>
</div></div></span></blockquote></body></html>