Hyperlinker: Hovering a name should show its type

[alexbiehl]

An interesting feature for our hyperlinked source backend. Hovering over a name should show its type:

Implementation should be straight forward. In https://github.com/haskell/haddock/blob/master/haddock-api/src/Haddock/Backends/Hyperlinker/Ast.hs we already collect all the information for each binder which we can use in the renderer.

In case of parameterized functions we could show the original type and the instantiated types on hover. This might give a nice experience when browsing sources.

/cc @harpocrates Interested?

[harpocrates]

Definitely interested - although I'm going to rework the constructor args stuff first. :)

[harpocrates]

@alexbiehl On closer examination - we aren't actually collecting the full types of things though, are we? This would mean holding on to quite a bit more information than we currently do...

[alexbiehl]

Yeah, I noticed that shortly after posting this. Currently we are working with the renamed source. For type information we need to work on the typed source and collect Ids instead of Names. It's a bigger project than previously thought. Alec Theriault <notifications@github.com> schrieb am Mi., 13. Dez. 2017, 21:58:

…

@alexbiehl <https://github.com/alexbiehl> On closer examination - we aren't actually collecting the full types of things though, are we? This would mean holding on to quite a bit more information than we currently do... — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#715 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AByiiUHK0QOVr8-3IlPQfa-HAPAYSl5Qks5tADpwgaJpZM4Q9H-C> .

[wz1000]

I'm about to start work on my GSOC project on Making GHC Tooling friendly which intends to get GHC to dump all the information haddock needs to generate hyperlinked source(basically a representation of the entire AST).

I was undecided whether to include type information in this file, but this issue makes a good case that it should be included.

If all goes well, --hyperlinked-source should essentially turn into a translator from .hie files to .html files. Similarly, haskell-ide-engine would become a program that responds to LSP queries by reading .hie files, cutting out the calls to GHC to compile stuff altogether.

/cc @alanz @bgamari @gbaz @hvr

[harpocrates]

Potentially relevant: #708.

[alexbiehl]

(Are you guys at Bayhack this week? btw.)

[gbaz]

I agree that including type information makes sense. If the general goal is an output format that external tools can use to do "most everything" without reinvoking GHC or using its API directly, then this would be a good thing. My only caution would be that the .hie project should proceed incrementally so as to avoid feature-creep dragging the entire thing down -- i.e. I don't want the scope of the project to inflate in such a way that rather than more stuff, we get nothing at all :-)

[alanz]

I think the other important factor is the interface provided to tooling to actually access this information.

So to support @gbaz, some sort of full life cycle demo of aninitial limited/uncontroversial data structure would probably make sense.

[harpocrates]

If all goes well, --hyperlinked-source should essentially turn into a translator from .hie files to .html files.

I am curious to see how you work around CPP for this. The more I think about this whole feature request, the less sure I am about what should be produced... I guess solving that is part of the fun!

[gbaz]

Ugh! CPP! How does the current hyperlinked-source module handle this? (and how does the ghc-exactprint stuff?)

[harpocrates]

hyperlinked-source has a bunch of (barely good-enough) heuristics for trying to split up the input into alternating CPP and non-CPP chunks. The GHC tokenizer gets run on the non-CPP segments. This lets us give tokens pretty colours without having more meaningful ASTs. Separately (and where .hie files are more obviously useful), the renamed source gets traversed SYB-style to collect linking information. That means that whatever CPP code path ended up being chosen to produce the renamed source is the only one that ends up having links and anchors.

…

On May 14, 2018, at 3:25 PM, gbaz ***@***.***> wrote: Ugh! CPP! How does the current hyperlinked-source module handle this? (and how does the ghc-exactprint stuff?) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#715 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AKRHARMXIRStPKqVd2G-rkdOZi3viMybks5tygQ_gaJpZM4Q9H-C>.

[gbaz]

So it sounds like we could do something similar here? In particular include the full (with cpp) source in the hie file, but only have the ast collect information on and point-into the portion of the source actually hit by whatever the result of evaling the cpp expression is.

Since we're only keeping the sketch- ast and not a full exact-printable ast, I don't think this project would replace the hyperlink-source stuff with regards to the tokenizing phase as you describe.

[harpocrates]

So it sounds like we could do something similar here?

I totally agree. I just wanted to point out that making --hyperlinked-source work entirely from .hie files might involve following a pretty deep CPP rabbit hole.

[wz1000]

An interesting possibility for future work could be a way to merge together .hie files that took different CPP pathways.

…

On Tue 15 May, 2018, 09:15 Alec Theriault, ***@***.***> wrote: So it sounds like we could do something similar here? I totally agree. I just wanted to point out that making --hyperlinked-source work *entirely* from .hie files might involve following a pretty deep CPP rabbit hole. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#715 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AElu0pIa8IKtM1A0SdjQfMfm7xQIy9kdks5tyk9agaJpZM4Q9H-C> .