Demand and strictness information

[serras]

GHC has a very powerful demand and strictness analyzer. The output is usually hidden, but can be shown using the -fstrictness flag. Reporting this information during compilation is not so useful; but a code editor seems to be like a great place to show this information. I am happy to put some work on this matter, but first we would need to figure out how to show this. Here are some ideas:

Show cardinalities on hover

In the same way that we show the type signature and the Haddocks when hovering over a symbol, we could also show the demand signature. GHC shows it in a very compact way (for example, the signature for fst is <1P(1L,A)>), but there's room for more explanation in the pop up window we get.

Highlight evaluation

Change the color or the appearance of a pattern to highlight that evaluation takes place. I'm imagining for example that if you write:

if_ True  t e = t
if_ False t e = e

Then True would change its color to explain that evaluation takes place there. The rest of the code is not highlighted, which means that neither t or e are evaluated as result of executing this function.

Semantic tokens is a LSP feature which seems like a candidate to implement this feature.

Show demand signatures

We could show the demand signature of each function on top of it, as a code lens, in the same way we do for signatures which the user hasn't written. However, I have no idea how this could be done in a non-intrusive way, thus I prefer the solution above of highlighting evaluation.

[jneira]

That sounds useful, specially for advanced haskellers, we even have a feature request about: #1925

[pepeiborra]

This would be lovely! Agreed that semantic tokens and hover details would be a better fit than code lenses. Please put this in a plugin, not in core ghcide, for easier maintenance.

I wonder how relevant the strictness analysis will be without the other simplifier passes.

[wz1000]

Sounds like a good idea! However, I would gate it behind configuration as the demand analyser is expensive to run (we don't usually run it in the IDE).

[serras]

Maybe the information about symbols is cheaper to obtain? I assume that should be somewhere in the .hi files or other by-product of the compilation.

[wz1000]

You mean symbols from external dependencies?

[serras]

Yes, let's say finding out the demand signature for map to show it in the hover info.

[wz1000]

Yeah, that would be in the strictnessInfo field of the IdInfo of the Id for map.

[jneira]

Yeah, moreover beginners can feel lost so i would set the plugin disabled by default at runtime via lsp config

[pepeiborra]

There is no nice support to disable plugins by default, right? Otherwise we would do it with the rename plugin as well

[jneira]

yeah, but we should add it following the suggestion from @berberman, i guess we will need it sooner or later, to disable globally a plugin or one of its capabilities

[michaelpj]

I would also find this handy! Perhaps it could be a full-on "GHC internal info" plugin and include e.g. all the stuff in IdInfo.

[michaelpj]

Related: #1925

[anka-213]

if it’s opt-in, then a code lens might not be a terrible option, especially if it is possible to enable it per file or something similar. when you’re specifically trying to analyze strictness, the extra noise doesn’t really hurt.

on the other hand, if it's possible to present all the information using semantic tokens, it might be a nicer interface