Re: [ANNOUNCE] GHC 8.2.1 release candidate 2

It's most certainly not a Cabal issue. The problem only manifests itself on packages which I have applied Nix's "doJailbreak", which mangles the .cabal file in order to remove bounds. Maybe the format of the .cabal has changed slightly and the parser it uses trips up? Anyway, sorry for the noise

RE: HsParTy

I can try to strip then all out and see what happens. That’d be good! With a Note to explain why… We still need ctxt_prec, I think, to pass to the ordinary type pretty-printer, when we have HsCoreTy. Simon From: Alan & Kim Zimmerman [mailto:alan.z...@gmail.com] Sent: 26 May 2017 12:14 To:

Re: HsParTy

When I was working through the ppr to use HsParTy everywhere it was not clear whether there were any usages that required maybeParen, so I left it in. I can try to strip then all out and see what happens. Alan On 26 May 2017 at 10:54, Simon Peyton Jones wrote: > Alan >

RE: Trees that Grow in the hsSyn AST

1. Which is better to start with: HsSyn or Core? Intuition suggests this sort of thing could be very helpful for making zapping more reliable and ensuring its efficiency, but there may be better reasons to start with HsSyn. Definitely HsSyn. It’s big, riddled with extra info, and has many

HsParTy

Alan Do you know why HsTypes.ppr_mono_ty contains any uses of 'maybeParen'? Shouldn't the parens all be put in by HsParTy? I tripped over this when I mistakenly added what I thought were missing maybeParen calls for HsAppTy and HsAppTys, but that was flagged as an error by a test in