Support GHC 9.0

[istathar]

So I started working theta-idl towards compiling on GHC 9.0

So far so good:

• most of the dependencies we had to add as "extra-deps" to the resolver in the stack.yaml file at lts-18.x are now available in lts-19.0 so I've tidied that up.
• base is now 4.15 so relax the upper bound there.

I've hit an actual code bug, though, related either to avro or our use of its Template Haskell facilities:

/home/andrew/src/daisee/theta-idl/theta/src/Theta/Target/Haskell.hs:631:51: error:
    • Couldn't match type ‘TH.Type’ with ‘TH.Exp’
      Expected: TH.Q TH.Exp
        Actual: TH.Q TH.Type
    • In the expression: TH.conT type_
      In the expression:
        [d| instance HasAvroSchema $(TH.conT type_) where
              schema
                = Tagged
                    $ case evalStateT toAvro Set.empty of
                        Left err -> error $ Text.unpack $ Theta.pretty err
                        Right res -> res
                where
                    toAvro = typeToAvro definitionAvroVersion thetaType
                    thetaType = theta @ ...
                    .... |]
        pending(rn) [<splice, TH.conT type_>, <splice, TH.conT type_>]
...

can't say as how I've got much idea what's going on in there, but perhaps you'll recognize that part of the code and have a notion of where to go from here (I get that Q Exp is expressions and Q Type is yeah, I'm just not sure why that would have changed).

[TikhonJelvis]

Huh, yeah, that's an odd error. No idea what changed and it seems correct to have a type in that location as opposed to an expression. I'll have to poke around to see what's going on.

[TikhonJelvis]

Meanwhile, looks like the Nix tests failed in CI too, but the logs were truncated. I'm going to push a changed version of the workflow config to fix that and see what's up.

[istathar]

I merged 'stage' into this branch but still the same build failure. I updated the code snippet above (it has qualified imports now) but it's the same error message.

[istathar]

I'm not sure if it's worth mentioning explicitly that this is built against latest avro version 0.6.1.0 and latest Stackage resolver lts-19.2.

[TikhonJelvis]

Pretty odd. Haven't been working much on Theta this week, but I should be able to update my setup for GHC 9 and reproduce the problem locally over the next few days.

[jack-davies]

Perhaps related?

https://gitlab.haskell.org/ghc/ghc/-/wikis/migration/9.0#typed-th-quotes-and-splices-have-different-types

[TikhonJelvis]

Turns out the problem was with type application syntax. I guess in theta @ $(...), @ got parsed as an operator. In normal Haskell I would not have a space after @, but in theta @$(...) the @$ gets parsed as an operator :P.

Pulling the type application outside the quasiquote solved the problem robustly:

where thetaType = TH.appTypeE [e|theta|] (TH.conT type_)

[istathar]

@TikhonJelvis What a glitch! I've heard older Haskell hands complain about language extensions changing the result of parsing, but this is the first time I've actually run into it. Huh!

Thanks very much for sorting this out. I think this was the last hurtle I'm going to go see if we can build with GHC 9.0 now!

[TikhonJelvis]

Interesting thought. I had assumed that @ was a valid operator before TypeApplications, but seems like @ doesn't parse as a normal infix operator and hasn't for at least a few years. It's a reserveop in the grammar going back at least to Haskell '98, but I don't know exactly how older GHCs handled it. As far as I understand it, this means that enabling TypeApplications could make previously invalid code parse correctly, but it should never change the meaning of expressions that parsed without it.

So, knowing that, there's no reason for TH to expect the righthand side of a @ to be an expression: with TypeApplications enabled it has to be a type and without the extension it should be a parse error.

Not entirely certain, but this could be a bug introduced into TH somewhere between GHC 8.10.7 and 9.0.2.