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