October 2021 - ghc-devs

Output language of typechecking pass?
by Benjamin Redelings 28 Dec '21

28 Dec '21

Hi, I have been looking for info on what actually comes out of the type-checking pass in GHC. This is mostly because it seems like the "Type classes in Haskell" paper implements both type checking and translation to dictionary-passing in one pass, whereas it seems like GHC separates this into (i) type checking and (ii) desugaring. Questions: 1. It seems like this separation is actually necessary, in order to apply generalization only to let arguments written by the programmer, and not to let bindings introduced during desugaring. Is that right? 2. Does the output of type checking contain type lambdas? 3. Does the type checking pass determine where to add dictionary arguments? 4. Are there any other resources I should be looking at? I am confused about #3, because the `-ddump-tc` output doesn't seem to show any type dictionaries in function bodies themselves, but it does seem to contain some kind of info about dictionaries as "evidence" -- but I am not sure what "evidence" is, or how it links into the AST for a function body. I did briefly look at `-ddump-tc-ast`, but not in detail yet. -BenRI

4 7

[ANNOUNCE] GHC 9.2.1 now available
by Ben Gamari 17 Nov '21

17 Nov '21

Hi all, The GHC developers are very happy to at long last announce the availability of GHC 9.2.1. Binary distributions, source distributions, and documentation are available at https://downloads.haskell.org/ghc/9.2.1 GHC 9.2 brings a number of exciting features including: * A native code generation backend for AArch64, significantly speeding compilation time on ARM platforms like the Apple M1. * Many changes in the area of records, including the new `RecordDotSyntax` and `NoFieldSelectors` language extensions, as well as Support for `DuplicateRecordFields` with `PatternSynonyms`. * Introduction of the new `GHC2021` language extension set, giving users convenient access to a larger set of language extensions which have been long considered stable. * Merging of `ghc-exactprint` into the GHC tree, providing infrastructure for source-to-source program rewriting out-of-the-box. * Introduction of a `BoxedRep` `RuntimeRep`, allowing for polymorphism over levity of boxed objects (#17526) * Implementation of the `UnliftedDataTypes` extension, allowing users to define types which do not admit lazy evaluation ([proposal]) * The new [`-hi` profiling] mechanism which provides significantly improved insight into thunk leaks. * Support for the `ghc-debug` out-of-process heap inspection library [ghc-debug] * Significant improvements in the bytecode interpreter, allowing more programs to be efficently run in GHCi and Template Haskell splices. * Support for profiling of pinned objects with the cost-centre profiler (#7275) * Faster compilation and a smaller memory footprint * Introduction of Haddock documentation support in TemplateHaskell (#5467) Finally, thank you to Microsoft Research, GitHub, IOHK, the Zw3rk stake pool, Tweag I/O, Serokell, Equinix, SimSpace, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Moreover, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do open a [ticket] if you see anything amiss. Happy testing, - Ben [apple-m1]: https://www.haskell.org/ghc/blog/20210309-apple-m1-story.html [proposal]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0265-u… [-hi profiling]: https://well-typed.com/blog/2021/01/first-look-at-hi-profiling-mode/ [ghc-debug]: http://ghc.gitlab.haskell.org/ghc-debug/ [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new

6 8

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

how to find Zero-boot packages with Hadrian?
by Norman Ramsey 26 Oct '21

26 Oct '21

What is the Hadrian equivalent of make show VALUE=BOOT_PKGS ?

2 2