Looks good to me - I think it probably makes the most sense to replace the current stack-ghc-8.0.yaml.

Thanks for your comment. I will update the PR in a while.

Actually come to think of it, what are the errors you get if you don't hide <|>?

Ambiguous occurrence ‘<|>’ occurs. It's because both Protolude and Data.Aeson.BetterErrors are exporting <|>.

Now I noticed that it may be better to just use aeson-better-errors-0.9.0.1?

Where is the occurrence?

Here: https://github.com/noraesae/purescript/blob/b132aa3dbd9215bde167f951ea73cd955518dfae/src/Language/PureScript/Docs/Types.hs#L408

Sorry that I am in another env and building again. I'd better pasting the error message itself when it's done.

Ah, right, thanks. Don't worry, I just wanted to check that we do want Alternative's <|> and not aeson-better-errors' there, and this does seem to be the case. I think it makes sense to stick with aeson-better-errors 0.9.1.0 because that's the one that's in Stackage LTS 7 and Nightly.

Thanks. Just replaced stack-ghc-8.0.yaml with stack-ghc-8.0.2.yaml.

I'd suggest calling the new GHC 8 stack.yaml stack-ghc-8.0.yaml like before: then we won't need to update things like CI scripts, and if people have set environment variables for working on purescript, those will continue to work.

Sorry for the ambiguity. It is exactly how I updated. The original stack-ghc-8.0.yaml is updated to use the new GHC.

Ah oops, I must have not been paying attention when I looked at the diff. Thanks! 😄

No worries. Thanks for your review!

It's going to be so great to be able to work on the compiler with my laptop again... thanks!

I've just realised one more thing: we should update the lower bound on aeson-better-errors in purescript.cabal to be 0.9.1.0, so that cabal won't try to choose it any more, because import Mod hiding (x) will cause a compile error if Mod does not actually export x.

In fact I guess it might be better still to switch that open import for an explicit import; that way we don't need to tighten the dependency bounds at all.

For example, src/Language/PureScript/Kinds.hs imports Data.Aeson.BetterErrors with explicit import. Would it be better to make other BetterErrors imports explicit? Data.Aeson.BetterErrors is currently imported in the following modules.

• src/Language/PureScript/Docs/RenderedCode/Types.hs
• src/Language/PureScript/Docs/Types.hs
• src/Language/PureScript/Kinds.hs
• src/Language/PureScript/Publish/ErrorsWarnings.hs
• src/Language/PureScript/Publish.hs

If it seems okay, I will upload an additional commit.

Yeah, I think it would be good to update all of those which don't already use an import of the form import Data.Aeson.BetterErrors (x, y, z, ...) so that they do. Thanks!

Although if one of those modules already uses qualified imports there's no need to change that; as you probably already know, it's just import Data.Aeson.BetterErrors and import Data.Aeson.BetterErrors hiding (...) that can cause this kind of problem.

Just uploaded the additional commit. None of them was imported as qualified, so just made them explicit.

No content change, name and email in commits were wrong, so I updated them.

Thanks!