- ghc-devs - Haskell.org

Interpreter thread in ghc-8.10.6 in macOS
by Domínguez, Facundo 16 Nov '21

16 Nov '21

Dear devs, I found recently that ghc-8.10.6 and ghc-8.10.7 might be behaving differently than previous compilers when running Template Haskell code. When upgrading HaskellR to use a newer ghc I found that it would work fine with ghc-8.10.4, but not ghc-8.10.6 or ghc-8.10.7. HaskellR, and the R runtime in particular, is sensitive to local state in the threads that are used to execute the runtime. HaskellR is arranging to run the R runtime when running TemplateHaskell splices, and this stopped working in MacOS with ghc-8.10.6. The error I got is not new. It comes from R and we would get it in ghci if we try to use HaskellR without passing the command line flag -fno-ghci-sandbox. But this is the first time we get the error when using TemplateHaskell. Does anyone know if there have been changes to the threads in which the TH splices are run? And were there any changes specific to TH in MacOS? Thanks in advance, Facundo [1] https://github.com/tweag/HaskellR/pull/368#issuecomment-968864170

3 4

request for comments: foreign calls (#20693)
by Norman Ramsey 16 Nov '21

16 Nov '21

I'd like it to be easier to extend GHC with support for new species of foreign calls. Existing support makes it easy to *replace* GHC's implementation of foreign calls but not to *extend* it. Details in #20693 (https://gitlab.haskell.org/ghc/ghc/-/issues/20693) I'd welcome comments, especially from anyone involved with GHCJS. Norman

1 0

Defaulting design choices
by Simon Peyton Jones 15 Nov '21

15 Nov '21

Sam, Richard, Adam, Vlad, Ryan, and other people interested in GHC's type system. Following discussion with Richard, I have created a new ticket #20686 for Make the design of defaulting explicit<https://gitlab.haskell.org/ghc/ghc/-/issues/20686>. This should inform !6851 which is trying to finish up Concrete# constraints. Please have a look - we 'd love your views on The Choice. Richard especially, but everyone really: feel free to edit the Description to make it more clear/accurate. I propose to treat it as our master design document. Simon PS: I am leaving Microsoft at the end of November 2021, at which point simonpj(a)microsoft.com<mailto:simonpj@microsoft.com> will cease to work. Use simon.peytonjones(a)gmail.com<mailto:simon.peytonjones@gmail.com> instead. (For now, it just forwards to simonpj(a)microsoft.com.)

1 0

Case split uncovered patterns in warnings or not?
by Sebastian Graf 10 Nov '21

10 Nov '21

Hi Devs, In https://gitlab.haskell.org/ghc/ghc/-/issues/20642 we saw that GHC >= 8.10 outputs pattern match warnings a little differently than it used to. Example from there: {-# OPTIONS_GHC -Wincomplete-uni-patterns #-}foo :: [a] -> [a]foo [] = []foo xs = ys where (_, ys@(_:_)) = splitAt 0 xsmain :: IO ()main = putStrLn $ foo $ "Hello, coverage checker!" Instead of saying ListPair.hs:7:3: warning: [-Wincomplete-uni-patterns] Pattern match(es) are non-exhaustive In a pattern binding: Patterns not matched: (_, []) We now say ListPair.hs:7:3: warning: [-Wincomplete-uni-patterns] Pattern match(es) are non-exhaustive In a pattern binding: Patterns of type ‘([a], [a])’ not matched: ([], []) ((_:_), []) E.g., newer versions do (one) case split on pattern variables that haven't even been scrutinised by the pattern match. That amounts to quantitatively more pattern suggestions and for each variable a list of constructors that could be matched on. The motivation for the change is outlined in https://gitlab.haskell.org/ghc/ghc/-/issues/20642#note_390110, but I could easily be swayed not to do the case split. Which arguably is less surprising, as Andreas Abel points out. Considering the other examples from my post, which would you prefer? Cheers, Sebastian

5 7

[RFC] Split the GHC.* hierarchy from `base` in its own package, `ghc-base`
by Hécate 08 Nov '21

08 Nov '21

Hello everyone, after a chat with Ben and seeing the idea thrown around, I have opened an RFC ticket to explore designs regarding a split of the GHC.* hierarchy from base, into its own package. The RFC is here: https://gitlab.haskell.org/ghc/ghc/-/issues/20647 Please do keep the comments in the ticket so that this discussion may be better archived. Cheers! -- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD

1 0

advice on minor cleanups?
by Norman Ramsey 08 Nov '21

08 Nov '21

All, It appears that `runHscBackendPhase` returns a tuple that include an element of type `Maybe Linkable` but that in practice is always `Nothing`. I'm thinking of removing this element from the tuple, which would also entail simplifying the type of value constructor `T_HscBackend` for the `TPhase` type. Simplifying the code seems like a good thing, but perhaps there is a reason to leave well enough alone? Please advise me. Norman

3 3

Alpha-equivalence for recursive let-bindings
by Christiaan Baaij 08 Nov '21

08 Nov '21

Hi list, I was looking at the `Eq (DeBruijn CoreExpr)` instance and I noticed that the types of recursive let-bindings aren't checked for alpha-equivalence: https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/Core/Map/Expr… go (Let (Rec ps1) e1) (Let (Rec ps2) e2) = equalLength ps1 ps2 && D env1' rs1 == D env2' rs2 && D env1' e1 == D env2' e2 where (bs1,rs1) = unzip ps1 (bs2,rs2) = unzip ps2 env1' = extendCMEs env1 bs1 env2' = extendCMEs env2 bs2 But doesn't that mean that: let (x :: Int) = x in x and let (y :: Bool) = y in y are considered alpha-equivalent? If that is the case, then I think that's wrong. Agree? I understand that you don't have to check types for non-recursive let-bindings: when the RHSs match, the types must be the same. -- Christiaan

2 2

8-bit and 16-bit arithmetic
by Norman Ramsey 29 Oct '21

29 Oct '21

On x86, GHC can translate 8-bit and 16-bit operations directly into the 8-bit and 16-bit machine instructions that the hardware supports. But there are other platforms on which the smallest unit of arithmetic may be 32 or even 64 bits. Is there a central module in GHC that can take care of rewriting 8-bit and 16-bit operations into 32-bit or 64-bit operations? Or is each back end on its own for this? (One of my students did some nice work on implementing this transformation with a minimal set of sign-extension and zero-extension operations: https://www.cs.tufts.edu/~nr/pubs/widen.pdf.) Norman

4 5

Re: Exact Print Annotations : Anchor in a SrcSpan
by Alan & Kim Zimmerman 29 Oct '21

29 Oct '21

I agree on not re-using accidentally available structures. But it got me thinking that maybe the BufSpan could be something else. I’m somewhat confused by the fact that we agreed to do it post-merge, but > all further work has been in some other direction. > > My work since the merge has been on consolidating the actual use-case for the exact print annotations, which means making sure that the (still external) ghc-exactprint library is still able to support the existing use-cases. My current driver for that is porting retrie[1] to use it, which has brought up the changes that I have been doing to GHC recently. Once that is done, I plan to update the in-tree exact printing to match, and then contemplate actioning plan B. Alan [1] https://github.com/alanz/retrie/tree/ghc-9.2

1 0

Exact Print Annotations : Anchor in a SrcSpan
by Alan & Kim Zimmerman 29 Oct '21

29 Oct '21

I have been updating the ghc-exactprint library for real world use cases on the about to be released GHC 9.2.1, and realised I need to be able to put an Anchor into every SrcSpan in the ParsedSource AST. I prepared !6854 to sort it out in master and turned to the problem of GHC 9.2.1, where I had missed the boat. And then I discovered that we have SrcSpan defined as data SrcSpan = RealSrcSpan !RealSrcSpan !(Maybe BufSpan) | UnhelpfulSpan !UnhelpfulSpanReason and the (Maybe BufSpan) is only used for attaching haddock comments after parsing. This means there is an isomorphism between the RealSrcSpan variant and an Anchor, which I take advantage of with the code in [1], by using the Maybe to encode the AnchorOperation and the BufSpan to encode the DeltaPos. And it struck me that perhaps we should make this a more official approach. The only problem is the detail of the BufSpan, to be able to play both roles cleanly. Alan [1] https://gist.github.com/alanz/5e262599ab79138606cdfcf3792ef635

3 2