dep: port to haskeline 0.8

[sorki]

Breaking change regarding MonadException which is now replaced
by MonadMask from exceptions package.

Allows building with GHC 8.10. This forces haskeline 0.8 so marking as draft for now.

[sjakobi]

Thanks for working on this! This should supersede my own WIP PR #540.

FWIW, in dhall, we retained backward compatibility with older versions of haskeline by replacing mtl-style type signatures with concrete ones. The main motivation was that we wanted to keep building dhall with older GHCs in Nix: dhall-lang/dhall-haskell#1717 (comment)

[sorki]

Oh, it's actually quite similar, missed that in a GHC 8.10 hurry! I don't know the policy we have here regarding GHC support but I guess supporting current pkgs.haskellPackages and also next candidate would be nice. I can add a bit of CPP if we want this sooner-ish.

[sjakobi]

Regarding GHC support, I think this is a fairly good rule of thumb:

At least 3 major versions and as many as can be supported without too much pain.

So, with GHC 8.10 being the most recent version, we should try to support at least 8.6, 8.8 and 8.10.

[sjakobi]

What's the status here, @sorki? Do you think we can get this into the upcoming release (#560)?

Since the Repl module is only used by the executable and not exposed via the library, I believe there's no need to keep function signatures as general as they are. We could simply use some concrete Repl e t f IO.

If you need any help, please shout! :)

[Ericson2314]

So the issue is the newer haskeline doesn't support the older GHC?

[sjakobi]

So the issue is the newer haskeline doesn't support the older GHC?

It does support older GHCs, but it's a boot library, and Gabriel convinced me that upgrading boot libraries is tricky with Nix: dhall-lang/dhall-haskell#1717 (comment)

That's about all I know! ;)

[sjakobi]

On second thought, since haskeline is only used by the executable, maybe we don't need to care about GHC compatibility so much. If the executable is only buildable with GHC >= 8.10 that shouldn't cause any problems for e.g. dhall-nix which uses only the library after all.

[sorki]

Yes, I've arrived at similar conclusion and even if we want to support older haskelline we can move the relevant instances to Repl.hs. For dependencies disabling executable would require override with isExecutable = false which is not ideal. I'll take a look again tomorrow.

[sorki]

So this is actually proving difficult - if I just move the instance from src/Nix/Standard.hs to main/Repl.hs it kind-of explodes on fundeps. I'm not sure what's the right thing to do here.

We could split Repl.hs into separate binary as a temporary workaround and only build it if haskeline >= 0.8 (not sure if that's possible either, might require flag). Don't quite like this solution but still, the library is more important for now I would say.

[sjakobi]

if I just move the instance from src/Nix/Standard.hs to main/Repl.hs it kind-of explodes on fundeps.

Are you referring to

instance MonadMask m => MonadMask (Fix1T StandardTF m)

?

Why is it necessary to move it?

[sorki]

No, I've tried to make it compatible with haskeline 7.4 by moving the old one like so:

#if !MIN_VERSION_haskeline(0,8,0)
instance MonadException m  => MonadException(StateT(M.HashMap FilePath NExprLoc) m)

Edit: explodes with https://gist.github.com/sorki/836997883d96247ee4298b6a83100980

Also I think this would still require bunch of #ifs due to MonadException contraint unless we move it somewhere better - you've suggested to specialize type annotations for repl functions but I'm not able to do so, not even for main.

[sjakobi]

OK. I actually don't see an important reason to keep supporting haskeline-0.7 any more.

If we need to turn off building the executable with GHC < 8.10, we can add something like this:

--- a/hnix.cabal
+++ b/hnix.cabal
@@ -963,6 +963,8 @@ executable hnix
     , unordered-containers
   if flag(optimize)
     ghc-options: -fexpose-all-unfoldings -fspecialise-aggressively -O2
+  if impl(ghc < 8.10)
+    buildable: False
   if impl(ghcjs)
     buildable: False
   default-language: Haskell2010

We should also be able remove the library dependency on haskeline now.

If you would like me to take this over @sorki, please shout! :)

[sorki]

@sjakobi thanks for the offer, wanted to give this a shot regarding compatibility but I will gladly accept at this point and your PR actually looks better, just needs the change(s) you've proposed for cabal.

Closing in favor #540 and thanks for the pointers as well!

[Anton-Latukha]

I would ask explicitly.
It seems like not our issue. It is upstream. Nixpkgs in our case.
Isn't it the definitive case when it can/should be solved by having 2 haskelline packages in Nixpkgs, one is an old version?
Nix lang is even smart enough to pick the right package for the right compiler, if the effort is put into that.

[Anton-Latukha]

Nixpkgs have no report/PR on that: https://github.com/NixOS/nixpkgs/search?q=haskeline&type=Issues
If there are such major troubles - the Report should be created there, and the Haskell label is pinned. If the question seems important to the community - even peti may be mentioned, because he sometimes opts-in to remove the support of old version in favor of the new version, because it is impossible to stop the progress.
Currently https://nixos.org/nixos/packages.html?channel=nixpkgs-unstable&query=haskeline there seems to be no separate haskeline 0.7 for a long time https://hackage.haskell.org/package/haskeline-0.7.5.0, it was 2019.09 when it was released, and 0.8 on 2019.12, so it seems too late.
Well, again - we may always dig up the Nixpkgs history and restore the old package version pretty easily.

It is an interesting question why there were no NixPkgs reports to preserve old haskeline.

[Anton-Latukha]

Since GHCJS builds in Nixpkgs - that means that implicitly provided haskeline 0.7.5 works.

That means there can be an easy override for its version:

haskeline = self.haskeline_0_7_5_0

In fact - this is how it is done in GHCJS.

[Anton-Latukha]

In fact, haskeline 0.7.5 seems to be in:

# pkgs/development/haskell-modules/configuration-hackage2nix.yaml

compiler: ghc-8.8.3

core-packages:
  - array-0.5.4.0
  - base-4.13.0.0
  - binary-0.8.7.0
  - bytestring-0.10.10.0
  - Cabal-3.0.1.0
  - containers-0.6.2.1
  - deepseq-1.4.4.0
  - directory-1.3.6.0
  - filepath-1.4.2.1
  - ghc-8.8.3
  - ghc-boot-8.8.3
  - ghc-boot-th-8.8.3
  - ghc-compact-0.1.0.0
  - ghc-heap-8.8.3
  - ghc-prim-0.5.3
  - ghci-8.8.3
  - haskeline-0.7.5.0
...
default-package-overrides:
...
  - haskeline ==0.7.5.0

Now we see that in fact - Nixpkgs haskeline means definite haskeline 0.7.5. Stuff compiles with it by default and uses it by default.

[Anton-Latukha]

And that most GHCs use bundled-in versions of libraries for self compilation:

./pkgs/development/haskell-modules/configuration-ghc-8.10.x.nix:  haskeline = null;
./pkgs/development/haskell-modules/configuration-ghc-8.8.x.nix:  haskeline = null;
./pkgs/development/haskell-modules/configuration-ghc-8.6.x.nix:  haskeline = null;
./pkgs/development/haskell-modules/configuration-ghc-8.4.x.nix:  haskeline = null;
./pkgs/development/haskell-modules/configuration-ghc-8.2.x.nix:  haskeline = null;

[sorki]

I don't think it's worth it keeping the support for old haskeline around and using nixpkgs overrides for hnix so it uses haskeline 0.7.5.

After the discussion here I've approved #540 which basically disables executable for GHC<8.10 which IMHO is not a big deal since

• library is more important currently
• if you want executable & repl it will still be easy to obtain it via pkgs.haskell.packages.ghc8101.hnix
• we'll eventually move to GHC 8.10 in few months, according to my testing it's not a big leap like GHC 8.6 -> GHC 8.8 was and only few packages needed fixes, mostly jailbreaks.

[Anton-Latukha]

I agree with you.

As I shown, currently all nixpkgs uses haskeline = haskeline 0.7.5 and there is separate haskeline_0_8_0_0.

So we would have something like haskeline = haskeline_0_8_0_0.

[sorki]

Hmm, looks like for me with haskell.packages.ghc8101 (@ rev="0010ae4960d35243e7abb046cd26ddda904a4c63") it's pulling v8 by default

$ ghc-pkg list | grep haskeline
    haskeline-0.8.0.0

but it might be useful for older ones to use haskeline = haskeline_0_8_0_0 iff needed.