- ghc-devs - Haskell.org

[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

Running GHC in GHCi
by Ben Gamari 28 Oct '21

28 Oct '21

Hi all, Today I verified that with Luite's recent work on the interpreter it is now possible to run GHC entirely within GHCi (when bootstrapping from GHC 9.2). Behold: ``` $ # First we must remove -fno-code from hadrian/ghci $ git apply <<EOF diff --git a/hadrian/ghci-cabal.in b/hadrian/ghci-cabal.in index 2a97b371802..f96919d91e1 100755 --- a/hadrian/ghci-cabal.in +++ b/hadrian/ghci-cabal.in @@ -6,4 +6,4 @@ set -e # Replace newlines with spaces, as these otherwise break the ghci invocation on windows. GHC_FLAGS="$GHC_FLAGS $(TERM=dumb CABFLAGS=-v0 "hadrian/build-cabal" tool:ghc/Main.hs -q --build-root=.hadrian_ghci --flavour=ghc-in-ghci $HADRIAN_ARGS | tr '\n\r' ' ')" -@WithGhc@ --interactive $GHC_FLAGS $@ -fno-code -fwrite-interface -hidir=.hadrian_ghci/interface -O0 +RTS -A128m +@WithGhc@ --interactive $GHC_FLAGS $@ -fwrite-interface -hidir=.hadrian_ghci/interface -O0 +RTS -A128m $ ./boot $ ./configure GHC=ghc-9.2 . . . $ hadrian/ghci GHCi, version 9.2.1: https://www.haskell.org/ghc/ :? for help [ 1 of 668] Compiling GHC.Iface.Type[boot] ( /opt/exp/ghc/ghc-landing/compiler/GHC/Iface/Type.hs-boot, interpreted ) [ 2 of 668] Compiling GHC.Platform.Constants ( /opt/exp/ghc/ghc-landing/.hadrian_ghci/stage0/compiler/build/GHC/Platform/Constants.hs, interpreted ) . . . [668 of 668] Compiling Main ( ghc/Main.hs, interpreted ) Ok, 668 modules loaded. λ> import Main λ> :set args -B/opt/exp/ghc/ghc-landing/_build/stage1/lib --version λ> :trace main The Glorious Glasgow Haskell Compilation System, version 9.3.20211027 λ> :set args -B/opt/exp/ghc/ghc-landing/_build/stage1/lib HelloWorld.hs λ> main [1 of 1] Compiling Main ( HelloWorld.hs, HelloWorld.o ) Linking HelloWorld ... λ> :! ./HelloWorld "Hello World!" ``` Surprisingly, performance isn't even horrible, taking only a few seconds to compile "hello world". Sadly, `:trace` doesn't quite work yet on `main`: ``` λ> :trace main *** Exception: ModBreaks.modBreaks_array not initialised CallStack (from HasCallStack): error, called at compiler/GHC/ByteCode/Types.hs:231:24 in ghc:GHC.ByteCode.Types ``` I've opened #20570 to track this issue. Fixing it would allow breakpoints and the like to be used on GHC. Anyways, I found this quite exciting. Perhaps this will spur more contributors to take an interest in GHCi. Cheers, - Ben

3 3

Resources on how to implement (Haskell 98) kind checking?
by Benjamin Redelings 27 Oct '21

27 Oct '21

Hi, I asked about this on Haskell-Cafe, and was recommended to ask here instead. Any help is much appreciated! 1. I'm looking for resources that describe how to implement kind Haskell 98 checking. Does anyone have any good suggestions? So far, the papers that I've looked at all fall short in different ways: * Mark Jones's paper "A system of constructor classes": This paper contains a kind-aware type-inference algorithm, but no kind inference algorithm. The closest it comes is the rule: C :: k' -> k and C' :: k' => C C' :: k * The THIH paper doesn't have an algorithm for kind checking. It assumes that every type variable already has a kind. * The 2010 Report helpfully mentions substituting any remaining kind variables with *. But it refers to "A system of constructor classes" for an algorithm. * The PolyKinds paper was the most helpful thing I've found, but it doesn't cover type classes. I'm also not sure that all implementers can follow algorithm descriptions that are laid out as inference rules, but maybe that could be fixed with a few hints about how to run the rules in reverse. Also, in practice I think an implementer would want to follow GHC in specifying the initial kind of a data type as k1 -> k2 -> ... kn -> *. * I've looked at the source code to GHC, and some of the longer notes were quite helpful. However, it is hard to follow for a variety of reasons. It isn't laid out like an algorithm description, and the complexity to handle options like PolyKinds and DataKinds makes the code harder to follow. 2. The following question (which I have maybe kind of answered now, but could use more advice on) is an example of what I am hoping such documentation would explain: > Q: How do you handle type variables that are present in class methods, > but are not type class parameters? If there are multiple types/classes > in a single recursive group, the kind of such type variables might not > be fully resolved until a later type-or-class is processed. Is there > a recommended approach? > > I can see two ways to proceed: > > i) First determine the kinds of all the data types, classes, and type > synonyms. Then perform a second pass over each type or class to > determine the kinds of type variables (in class methods) that are not > type class parameters. > > ii) Alternatively, record the kind of each type variable as it is > encountered -- even though such kinds may contain unification kind > variables. After visiting all types-or-classes in the recursive > group, replace any kind variables with their definition, or with a * > if there is no definition. > > I've currently implement approach i), which requires doing kind > inference on class methods twice. > Further investigation revealed that GHC takes yet another approach (I think): iii) Represent kinds with modifiable variables. Substitution can be implemented by modifying kind variables in-place. This is (I think) called "zonking" in the GHC sources. This solves a small mystery for me, since I previously thought that zonking was just replacing remaining kind variables with '*'. And indeed this seems to be an example of zonking, but not what zonking is (I think). Zonking looks painful to implement, but approach (i) might require multiple passes over types to update the kind of type variables, which might be worse... 3. I'm curious now how many other pieces of software besides GHC have implemented kind inference... -BenRI

3 5

Meaning of -i and -hidir
by Domínguez, Facundo 27 Oct '21

27 Oct '21

Dear devs, I'm confused about the meaning of -hidir and -i. Here's my experiment with both ghc-9.2.0 and ghc-8.10.4. > $ find > ./Main.hs > ./lib/Lib.hs > > $ ghc -dynamic-too -c lib/Lib.hs -odir odir -hidir hidir_Lib > > $ ghc -dynamic-too -c Main.hs -odir odir -ihidir_Lib -hidir hidir_Main > > Main.hs:3:1: error: > Bad interface file: hidir_Main/Lib.hi > hidir_Main/Lib.hi: openBinaryFile: does not exist (No such file or directory) > | > 3 | import Lib > | ^^^^^^^^^^ If I only use -hidir, it still fails with another error > $ ghc -dynamic-too -c Main.hs -odir odir -hidir hidir_Lib > > Main.hs:7:29: error: Variable not in scope: f > | > 7 | main = print $(runIO (print f) >> [| True |]) > | ^ If I use both -i and -hidir pointing to the same folder, then it works! > $ ghc -dynamic-too -c Main.hs -odir odir -ihidir_Lib -hidir hidir_Lib Now, is this behavior a bug or a feature? And if it is a bug, what is the expected behavior? Programs copied below. Thank you! Facundo > $ cat lib/Lib.hs > module Lib where > > f :: Int > f = 1 > > $ cat Main.hs > {-# LANGUAGE TemplateHaskell #-} > > import Lib > import Language.Haskell.TH <http://language.haskell.th/> > > main :: IO () > main = print $(runIO (print f) >> [| True |])

6 7

How to use Lexer.lexer to produce closing braces as well?
by Kwanghoon Choi 26 Oct '21

26 Oct '21

Hi, I have recently been playing with GHC's Lexer.lexer in the ghc-parser-lib package. Given module HelloWorld where main = putStrLn "Hello World!\n" it produces stack exec -- lexer-exe ./examples/HelloWorld.hs Lexing&Parsing: ./examples/HelloWorld.hs module at (1, 1): module CONID at (1, 8): CONID where at (1, 19): where vocurly at (3, 1): vocurly <==== { is inserted automatically!! VARID at (3, 1): VARID = at (3, 6): = VARID at (3, 8): VARID STRING at (3, 17): STRING ; at (4, 1): ; By the example above, the lexer automatically inserts an opening brace (i.e. vocurly) right after 'where'. But it does not insert a matching closing brace (i.e., vccurly), which would lead to a failure in parsing a list of tokens produced by the lexer. My question is how to use the GHC lexer to produce closing braces as well. All my code is available - https://github.com/kwanghoon/hslexer To save your time, the relevant part of the code is as follows: In app/HaskellLexer.hs, singleHaskellToken :: P (Located Token) singleHaskellToken = Lexer.lexer False (\locatedToken -> P (\pstate -> POk pstate locatedToken)) tokInfos :: [Terminal Token] -> P (Line, Column, [Terminal Token]) tokInfos s = do locatedToken <- singleHaskellToken case locatedToken of L srcspan ITeof -> let (start_line, start_col, end_line, end_col) = srcSpanToLineCol srcspan in return (end_line, end_col, s) L srcspan tok -> let (start_line, start_col, end_line, end_col) = srcSpanToLineCol srcspan in tokInfos (Terminal (fromToken tok) start_line start_col (Just tok) : s) Thanks in advance Best regards, Kwanghoon

2 2