Getting VSCode/HLS to work with Drasil

[balacij]

Right now, VSCode's best Haskell support is from the official Haskell plugin. Unfortunately, the backend of the plugin, Haskell Language Server, only supports a handful of GHC versions (8.6.4, 8.6.5, 8.8.2, 8.8.3, 8.8.4, 8.10.1, and 8.10.2).

As such, I was wondering if it would be alright to update our GHC target/dependency so that we may use one of the versions supported by the Haskell Language Server (and hence the VSCode plugin).

If we are to update our GHC target, then I assume we would want to target something stable and well-supported, such as to GHC 8.8.4 (8.10.* does not yet seem to be supported by Stack in LTS, but 8.8.4 is also the most recent LTS of Stack LTS-16.31)

Additionally, I assume we would need to also update some of our libraries to be compilable against one of these higher GHC versions. If I'm not mistaken, we are currently using stack with cabal build files, which I believe is no longer recommended by Stack. Their documentation seems a bit out of date/confusing but they seem to say that the cabal file should be built automatically through hpack/package.yaml (meaning that the recommended way is to only interact with stack.yaml and package.yaml, and to use hpack to generate the cabal file [which is done automatically when we run stack build/stack install/stack exec hpack]). Related: https://docs.haskellstack.org/en/stable/GUIDE/#adding-dependencies

I've gone ahead and taken a peek at our total dependency list (using cd code && stack ls dependencies to gather them, which I hope is sufficient) and have found that most packages either have minor (as per semantic versioning) or no updates in comparison with ours, so the change of breakage might be minimal. However, 5 of the dependencies are not listed on Stackage (the rest appear to be), so they might require some unknown amount of manual work to get them to work again with the entire system. I'm not entirely sure the extent of work of which is required yet.

The following 5 packages are not found on Stackage/LTS-16.31 (but we can likely still get them from Hackage/somewhere else using extra-deps in package.yaml):

ghc-boot-th 8.6.5                      (Hackage, does not appear to support 8.8.4 but does support 8.8.3, 8.10, 8.10.2, so I assume a straight forward process for getting support for 8.8.4)
multiplate 0.0.3                       (Hackage, unknown support)           
rts 1.0                                (unknown)
unicode-names 3.2.0.0                  (Hackage, unknown support)
unicode-properties 3.2.0.0             (Hackage, unknown support)

Related: https://www.stackage.org/lts-16.31

I believe (but not entirely certain) that this would help with getting VSCode/HLS to support Drasil fully. This might also be helpful for the students coming in the Summer term to work on Drasil as well.

As such, I am wondering if it would be okay to attempt to update our GHC target and the packages with it, while also converting the inner packages to stack.yaml/package.yaml Stack projects. This second part of converting our cabal files to package.yaml/stack.yaml files may be unnecessary but it may also simplify future updates to our GHC version should we choose to do so again.

(Maybe this is too much work for the goal of getting HLS support and I should just use another IDE? I might also be understanding the various errors created from the VSCode Haskell plugin but this work doesn't seem like it would hurt anything to try [or maybe it would?])

Thank you!

[balacij]

master...balacij:2292_stack_packages

Writing up the proof of concept, not yet complete but it seems to solve my problem. Let me know what you think!

EDIT:
TODO list:

• Drasil/code/drasil-code/Language/Drasil/Code/Imperative/Parsers/ConfigParser.hs

  Line 20 in 0802004

  import Language.Drasil.Code.Imperative.GOOL.LanguageRenderer (Options(..))

  -- Should this be causing an import issue? Seems like it but I haven't figured out how to resolve it yet.

• Drasil/code/drasil-code/Language/Drasil/Code/AST.hs

  Line 36 in 0802004

  Calculation :: EqChunk -> Objective

  -- Is EqChunk supposed to be replaced with QDefinition here? Seems to cause a compilation error if left as EqChunk (will discuss this and the above with Dr. Carette at a later point in time)
• drasil-code; package.yaml currently not in use, manual cabal file being used to remove ConfigParser because it isn't compiling at the moment
• Double check license version we use (BSD2?) and propagate across new package.yaml files (opting to do this later if we want this)
• Remove autogenerated comments from all of the new package.yaml files
• All versioning rules seem to be ">= X version", check if Stack automatically picks up the latest ones and if we can remove these minimums

EDIT 2: I ran through all of the CI steps in the travis configuration and it appears to work.