Remove `haskell-doc-prelude-types` from `haskell-doc.el`

[geraldus]

Since we already rely on GHC output for supported language extensions and pragmas why not to drop haskell-doc-prelude-types from haskell-doc.el? This could be done parsing output of ghc -e ':bro Prelude'.

One caveat: now stack allows multiple GHC versions without any global GHC compiler in PATH, I think we should add these variables to session when starting new interactive process and populate them running stack exec -- ghc … because different versions of GHC possibly could have different Preludes and options/extensions. Then in case of presence interactive session associated to current buffer completion and doc-string providers should use session variables instead of global ones.

[gracjan]

Actually I was about to propose exactly opposite direction: that is NOT populating pragmas and extenstions dynamically from the ghc available in PATH, instead prepopulate both in the source code as a set union of all options available on all compilers from 7.2 to 8.0.

It is just me who is bothered that the ghc that happens to be found in the PATH is some dysfunctional random installation that I forgot to remove?

[geraldus]

prepopulate both in the source code as a set union of all options available on all compilers from 7.2 to 8.0

It's tedious but pretty simple. Can we even further and populate this things using Travis automatically when merging stuff in master branch? For example create some template files, and make Travis generate required lists running same command for custom set of compilers then run normal build and test routine and finally somehow commit these files to master?
Or maybe to have some submodule git repository containing these variables which is updated once when new GHC version is added? (So, all this paragraph can be re-worded to "can we automate this?")

On other hand, how haskell-mode will choose what list to use for arbitrary source file?

It is just me who is bothered that the ghc that happens to be found in the PATH is some dysfunctional random installation that I forgot to remove?

I don't bothered with this, however I always keep this possibility in mind.

[gracjan]

Yes, automation is king.

I think we should have a script that adds items to lists. So when a new compiler version is released all the missing flags or extensions are added to the list. Each item on the list could have attached a version of the compiler when it was seen first time.

The lists should just accumulate stuff, so that completion can propose any of the options of any of the versions of a compiler.

[geraldus]

One last caveat how to generate keyword list or just leave it hard-coded?

[gracjan]

Hard coded. This does not change that often :)

[geraldus]

Related #1194
Closing this one