Maintaining haskell programs

5

It’s difficult to tell without knowing the explicit problem he faced. I agree the interactions among cabal-ghc-stack-hls might be difficult. For example:

  • if you want to use a non stackage package in a stack project you have to modify stack.yaml and package.yaml/.cabal. This is well documented in stack's user guide, so I am not blaming stack for this, but in general we should warn people that developer do not read documentation at all (hyperbole), so instead of writing a nice user guide is much better to throw a big and explicit error with “you are doing this and that wrong”. I can imagine someone having trouble with this ending up with a mess of environment difficult to maintain.

  • ghc extension ecosystem is a mess. 9 out of 10 times, I don’t know what they do; I just turn them on because the compiler suggest them in an cryptic error message. Moreover, extensions can break other extensions, and compiler updates might change the behaviour of type-level extensions. For example:

    • I’ve been trying to use effectul library recently, It turns out that with GHC2021 extension it doesn’t compile, you have to use Haskell2010 and a bunch of extension. This mean that there is at least one extension within GHC2021 which breaks all other code. The error is something about illegal kind {k}. Please use optimus-prime kind level programming to solve skolem-curry paradox and break the simulation we live on.… yes, I made that up but to me the error message was as cryptic as that (the real error was related to kinds actually)
    • Also, having so many extensions creates some sort of “type system a la carte”, super difficult to undestand and maintain. If you want to use something like vector-sized you must activate many extension and deactivate(!!) others like StarIsType… which is weird because up to the documentation using * as type is legacy, but GHC2021 do include it(?).

  • In my computer hls performs horrible with ghc-9.4.5. Imagine updating the compiler and the language server works… but works very bad.

  • cabal prefers to download new package versions instead of using the one already in the system (is there any flag like --prefer-installed??). If you copy paste code from a project to another within you own computer I might happen that you download different versions in each project leading to compilation fails in the new version, which can’t be ported to the old one. Yes, this is bad user behaviour because we should add dependency bounds in the cabal file, but even then, if your bounds aren’t tight enough, you may end up in this situation

So these are a few example on how maintainbility can be difficult when you update the compiler, or libraries or you simply copy code from other place.

5 Likes