Allow aeson 2.0

[sjakobi]

https://hackage.haskell.org/package/aeson-2.0.0.0/changelog

---

Blocked on:

• Required by dhall:
  • Doesn't build with aeson >=2 informatikr/aeson-pretty#36
  • Compatibility with aeson-2.0 snoyberg/yaml#201
  • Support aeson-2.0 well-typed/cborg#270
• Required by other packages:
  • Compatibility with aeson-2.0 clovyr/aeson-yaml#16 (needs release)
  • Support for aeson >= 2 haskell-hvr/HsYAML-aeson#11
  • Compatibility with aeson 2.0 haskell-nix/hnix#991 (needs another release. v0.15.0 is deprecated)

[Gabriella439]

I wasn't sure if this is safe to merge or if we're still waiting on upstream to fix their bounds before we can test this

[sjakobi]

@Gabriel439 I think we'll need to wait at least for informatikr/aeson-pretty#36 in order to build dhall with aeson-2.

[hasufell]

aeson-pretty is abandoned (there was a reddit thread asking for package takeover)

[sjakobi]

Yeah, I saw the reddit thread at https://www.reddit.com/r/haskell/comments/qape11/aesonpretty_request_for_new_maintainer/.

Seems like u/callbyneed is stepping up as a maintainer, so I'm optimistic for now.

[Gabriella439]

Feel free to merge this whenever you're ready

[sjakobi]

I'm running into a weird issue with a compat change in Dhall.JSON. When I add {-# LANGUAGE CPP #-} to the top of the file, I get the following parse error from GHC:

src/Dhall/JSON.hs:272:204: error:
    lexical error in string/character literal at character 'E'
    |
272 |             _ERROR <> ": ❰None❱ is not valid on its own                                      \n\
    |                                                                                                                                                                                                            ^

I've tested with GHC 8.6.5, 8.8.4, 8.10.7 and 9.0.1. This looks like a bug in GHC or the C-preprocessor, right?!

EDIT: If I add the pragma to Dhall.TypeCheck, I get a similar error.

[sjakobi]

I'm running into a weird issue with a compat change in Dhall.JSON.

I worked around that issue by keeping the CPP in a new module Dhall.JSON.Compat.

[sjakobi]

I have reverted the bounds bump in dhall-lsp-server. I think we'll need to address #2270 before we can make that package compatible with aeson-2.

Since I've pushed some code changes, could you do a quick review, @Gabriel439?

[sjakobi]

I'm running into a weird issue with a compat change in Dhall.JSON. When I add {-# LANGUAGE CPP #-} to the top of the file, I get the following parse error from GHC:

I seem to have hit https://gitlab.haskell.org/ghc/ghc/-/issues/10230.

If this keeps bugging us, we could probably start using QuasiQuotes / neat-interpolation again. I think that would be more readable and maintainable too.

The original motivation for avoiding QQ seems to have been dhall-lang/dhall-json#12 / ghcjs/ghcjs#617, which seems to have been fixed upstream.

[Gabriella439]

@sjakobi: Yeah, I would be fine restoring the use of QuasiQuotes. Also, we should try using string-interpolate instead of neat-interpolation because the string-interpolate package is a little bit more featureful

[hasufell]

string-interpolate increases compile times noticeably, I think due to haskell-src-* packages.

[sjakobi]

we should try using string-interpolate instead of neat-interpolation because the string-interpolate package is a little bit more featureful

What features are you looking for? Note that neat-interpolation has gained an untrimming variant, although the precise difference to trimming / text is not quite clear to me.

[Gabriella439]

The main feature of string-interpolate that appeals to me is that you can interpolate arbitrary Haskell expressions (instead of just variables)

[hasufell]

Maybe consider https://discourse.haskell.org/t/pyf-0-10-0-1-format-multi-lines-string/3540/2 which doesn't use haskell-src-ext anymore.

Prelude PyF> putStrLn [fmt|{take 2 ['c','b','d']}|]
cb

[sjakobi]

@hasufell PyF looks interesting! Does it support un-indenting multiline strings, like neat-interpolation?

[hasufell]

@sjakobi I'm not sure, the only thing about multi-line strings in the README is here: https://github.com/guibou/PyF#multi-line-strings

[sjakobi]

While the update to dhall-json includes code changes, I realized that for dhall, dhall-yaml, dhall-nixpkgs and dhall-openapi, Hackage revisions would be sufficient, so I've published these.