Ineffective strict data fields

[tomjaguarpaw]

I read in https://mpickering.github.io/ide/posts/2020-05-08-state-of-haskell-ide.html and subsequently https://lukelau.me/haskell/posts/leak/ about space leaks in haskell-ide-engine. Whilst browsing the code I noticed that there are some strict data fields where space leaks may still hide. At the very least, the strict data fields are not doing what you think they are doing.

Firstly there are occurrences of !(Map.Map ...) [1] [2]. Throughout the codebase the Data.Map API is used, which is lazy, instead of the Data.Map.Strict API, which is strict. Generally this will mean that forcing the map does absolutely nothing at all.

Troublesome functions include insert, insertWith, adjust and alter. Any value stored in a map using those functions will not be forced by forcing the map. With careful thought you could determine which usages really have to be strict and use the strict API for them only, but it's probably best if you apply the sledgehammer of just switching to Data.Map.Strict everywhere. This will be fine unless you are using maps to store things that really need to remain unevaluated.

Secondly there are a couple of occurrences of !(Maybe ...) [1] [2]. Forcing a Maybe only forces its constructor. If it is a Just the inner value will not be forced. Therefore it's likely that you have unevaluated TypeCheckedModules floating around. (The former case of !(Maybe (IORef ...)) is less worrisome: I would be surprised if IORefs can be created in an unevaluated state, though I am not certain).

This situation is harder to resolve. You have to make sure that every time you modify the ghcSession field you force it one level deeper than seq would. This is very fiddly work and I the only easy suggestion I have is the unpleasant one of switching to a StrictMaybe type.

[jneira]

Thanks for your suggestions, they seem reasonable.
However actually the main effort is focused in haskell-language-server and this repo is in maintance mode.