- ghc-devs - Haskell.org

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

How to close an issue that won't happen?
by Norman Ramsey 26 Oct '21

26 Oct '21

Issue #20370 is not going to happen. I have added a comment of explanation, and it's time for me to close the issue. What label, if any, should I put on the issue to indicate that it describes a direction we've decided not to pursue? Norman

2 1

RE: Specialisation doesn't kick in -- NOW WITH MINIMAL WORKING EXAMPLE (RE: Instantiation of overloaded definition *in Core*)
by Erdi, Gergo 25 Oct '21

25 Oct '21

PUBLIC PUBLIC OK I now have a standalone demonstrator that shows, at least, that the default method implementation is not specialized. With the attached input programs, the resulting Core (using GHC e46edfcf47d674731935b2ea1443cc7927e071fb) is as follows (only showing the relevant parts): seq :: forall (m :: * -> *) a b. Monad m => m a -> m b -> m b seq = \ (@(m :: * -> *)) (v_srS [Occ=Once1!] :: Monad m) -> case v_srS of { C:Monad _ [Occ=Dead] v_srV [Occ=Once1] -> v_srV } $dmseq :: forall (m :: * -> *) a b. Monad m => m a -> m b -> m b $dmseq = \ (@(m :: * -> *)) ($dMonad [Occ=Once1] :: Monad m) (@a) (@b) (ma [Occ=Once1] :: m a) (mb [Occ=OnceL1] :: m b) -> let { sat_ss0 [Occ=Once1] :: a -> m b [LclId] sat_ss0 = \ _ [Occ=Dead] -> mb } in bind @m $dMonad @a @b ma sat_ss0 $fMonadIO :: Monad IO $fMonadIO = C:Monad @IO bindIO $fMonadIO_$cseq; $fMonadIO_$cseq :: forall a b. IO a -> IO b -> IO b $fMonadIO_$cseq = \ (@a) (@b) -> $dmseq @IO $fMonadIO @a @b; foo :: IO () foo = seq @IO $fMonadIO @() @() ioA ioA If I turn on Opt_D_dump_spec, I can see that specializer *is* running, it just doesn't *do* anything. From: Erdi, Gergo Sent: Monday, October 11, 2021 4:00 PM To: Simon Peyton Jones <simonpj(a)microsoft.com>; Matthew Pickering <matthewtpickering(a)gmail.com> Cc: Montelatici, Raphael Laurent <Raphael.Montelatici(a)sc.com>; 'GHC' <ghc-devs(a)haskell.org> Subject: RE: Specialisation doesn't kick in (RE: Instantiation of overloaded definition *in Core*) PUBLIC Trust me when I say I understand your frustration. It is even more frustrating for me not to be able to just send a Github repo link containing my code... I'll try to make an MWE that demonstrates the problem but it will probably take quite some time. I was hoping that maybe there's some known gotcha that I'm not aware of - for example (see my other thread), I just discovered that setting optimization flags one by one isn't equal to setting them wholesale with -On, so I was *not* running specialisation in my normal (per-module) pipeline at all! Unfortunately, now that I've discovered this and made sure optLevel is set to at least 1, I am still seeing the polymorphic default implementation of >> as the only one :/ I also tried to be cheeky about the binding order and put the whole collected CoreProgram into a single Rec binder to test your guess, since that should make the actual textual order irrelevant. Unfortunately, that sill doesn't change anything :/ From: Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> Sent: Monday, October 11, 2021 3:33 PM To: Erdi, Gergo <Gergo.Erdi(a)sc.com<mailto:Gergo.Erdi@sc.com>>; Matthew Pickering <matthewtpickering(a)gmail.com<mailto:matthewtpickering@gmail.com>> Cc: Montelatici, Raphael Laurent <Raphael.Montelatici(a)sc.com<mailto:Raphael.Montelatici@sc.com>>; 'GHC' <ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org>> Subject: [External] RE: Specialisation doesn't kick in (RE: Instantiation of overloaded definition *in Core*) PUBLIC ATTENTION: This email came from an external source. Do not open attachments or click on links from unknown senders or unexpected emails. Always report suspicious emails using the Report As Phishing button in Outlook to protect the Bank and our clients. It's incredibly hard to debug this sort of thing remotely, without the ability to reproduce it. First, you are using a variant of GHC, with changes that we can only guess at. Second, even with unmodified GHC I often find that unexpected things happen - until I dig deeper and it becomes obvious! There is one odd thing about your dump: it seems to be in reverse dependency order, with functions being defined before they are used, rather than after. That would certainly stop the specialiser from working. The occurrence analyser would sort this out (literally). But that's a total guess. 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<mailto:simonpj@microsoft.com>.) From: Erdi, Gergo <Gergo.Erdi(a)sc.com<mailto:Gergo.Erdi@sc.com>> Sent: 11 October 2021 03:58 To: Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>>; Matthew Pickering <matthewtpickering(a)gmail.com<mailto:matthewtpickering@gmail.com>> Cc: Montelatici, Raphael Laurent <Raphael.Montelatici(a)sc.com<mailto:Raphael.Montelatici@sc.com>>; 'GHC' <ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org>> Subject: RE: Specialisation doesn't kick in (RE: Instantiation of overloaded definition *in Core*) PUBLIC PUBLIC Hi Simon, Matt & others, It took me until now to be able to try out GHC HEAD, mostly because I had to adapt to all the GHC.Unit.* refactorings. However, now I am on a466b02492f73a43c6cb9ce69491fc85234b9559 which includes the commit Simon pointed out. My original plan was to expose the first half of specProgram, i.e. the part that calls `go binds`. I did that because I want to apply specialisation on collected whole-program Core, not just whatever would be in scope for a Core-to-Core plugin pass, so I am not writing a CoreM and I don't even have a ModGuts at hand. However, I found out from Matt's email on this thread that this is not going to be enough and eventually I'll need to figure out how I intend to apply the rewrite rules that come out of this. So for now, I am just turning on specialization in the normal pipeline by setting Opt_Specialise, Opt_SpecialiseAggressively, and Opt_CrossModuleSpecialise. And I'm still not seeing $dm>> being specialized. Is this because I define each of "class Monad", "data IO a", "instance Monad IO", and "main", in four distinct modules? In other words, is this something I will not be able to try out until I figure out how to make a fake ModGuts and run a CoreM from outside the normal compilation pipeline, feeding it the whole-program collected CoreBinds? But if so, why is it that when I feed my whole program to just specBinds (which I can try easily since it has no ModGuts/CoreM dependency other than a uniq supply and the CoreProgram), I get back an empty UsageDetails? Thanks, Gergo For reference, the relevant definitions dumped from GHC with specialization (supposedly) turned on: main = $fMonadIO_$c>> @() @() sat_sJg xmain $fMonadIO_$c>> :: forall a b. IO a -> IO b -> IO b $fMonadIO_$c>> = \ (@a_aF9) (@b_aFa) -> $dm>> @IO $fMonadIO @a_aF9 @b_aFa; $dm>> :: forall (m :: Type -> Type) a b. Monad m => m a -> m b -> m b $dm>> = \ (@(m_ani :: Type -> Type)) ($dMonad_sIi [Occ=Once1] :: Monad m_ani) (@a_ar4) (@b_ar5) (ma_sIj [Occ=Once1] :: m_ani a_ar4) (mb_sIk [Occ=OnceL1] :: m_ani b_ar5) -> let { sat_sIm [Occ=Once1] :: a_ar4 -> m_ani b_ar5 [LclId] sat_sIm = \ _ [Occ=Dead] -> mb_sIk } in >>= @m_ani $dMonad_sIi @a_ar4 @b_ar5 ma_sIj sat_sIm From: Erdi, Gergo Sent: Thursday, October 7, 2021 9:30 AM To: Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> Cc: Montelatici, Raphael Laurent <Raphael.Montelatici(a)sc.com<mailto:Raphael.Montelatici@sc.com>>; GHC <ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org>> Subject: RE: Specialisation doesn't kick in (RE: Instantiation of overloaded definition *in Core*) PUBLIC Indeed, I am using 9.0.1. I'll try upgrading. Thanks! From: Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> Sent: Wednesday, October 6, 2021 6:12 PM To: Erdi, Gergo <Gergo.Erdi(a)sc.com<mailto:Gergo.Erdi@sc.com>> Cc: Montelatici, Raphael Laurent <Raphael.Montelatici(a)sc.com<mailto:Raphael.Montelatici@sc.com>>; GHC <ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org>> Subject: [External] RE: Specialisation doesn't kick in (RE: Instantiation of overloaded definition *in Core*) Grego, Yes I think that should auto-specialise. Which version of GHC are you using? Do you have this patch? commit ef0135934fe32da5b5bb730dbce74262e23e72e8 Author: Simon Peyton Jones simonpj(a)microsoft.com<mailto:simonpj@microsoft.com> Date: Thu Apr 8 22:42:31 2021 +0100 Make the specialiser handle polymorphic specialisation Here's why I ask. The call $fMonadIO_$c>> = \ (@a) (@b) -> $dm>> @IO $fMonadIO @a @b indeed applies $dm>> to $fMonadIO, but it also applies it to a and b. In the version of GHC you have, maybe that stops the call from floating up to the definition site, and being used to specialise it. Can you make a repro case without your plugin? 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<mailto:simonpj@microsoft.com>.) This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at https: //www.sc.com/en/our-locations Where you have a Financial Markets relationship with Standard Chartered PLC, Standard Chartered Bank and their subsidiaries (the "Group"), information on the regulatory standards we adhere to and how it may affect you can be found in our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and Regulatory Compliance Disclosures at http: //www.sc.com/rcs/fm Insofar as this communication is not sent by the Global Research team and contains any market commentary, the market commentary has been prepared by the sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied on for any other purpose and is subject to the relevant disclaimers available at https: //www.sc.com/en/regulatory-disclosures/#market-disclaimer. Insofar as this communication is sent by the Global Research team and contains any research materials prepared by members of the team, the research material is for information purpose only and shall not be relied on for any other purpose, and is subject to the relevant disclaimers available at https: //research.sc.com/research/api/application/static/terms-and-conditions. Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign the term sheet to acknowledge the same. Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for important information with respect to derivative products. This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at https: //www.sc.com/en/our-locations Where you have a Financial Markets relationship with Standard Chartered PLC, Standard Chartered Bank and their subsidiaries (the "Group"), information on the regulatory standards we adhere to and how it may affect you can be found in our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and Regulatory Compliance Disclosures at http: //www.sc.com/rcs/fm Insofar as this communication is not sent by the Global Research team and contains any market commentary, the market commentary has been prepared by the sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied on for any other purpose and is subject to the relevant disclaimers available at https: //www.sc.com/en/regulatory-disclosures/#market-disclaimer. Insofar as this communication is sent by the Global Research team and contains any research materials prepared by members of the team, the research material is for information purpose only and shall not be relied on for any other purpose, and is subject to the relevant disclaimers available at https: //research.sc.com/research/api/application/static/terms-and-conditions. Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign the term sheet to acknowledge the same. Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for important information with respect to derivative products.

4 9

Another hadrian option you might want to use
by Matthew Pickering 24 Oct '21

24 Oct '21

Hi, A recent change in the testsuite meant that we now running the haddock tests with hadrian, this means that haddocks for ghc/base get rebuilt if you modify anything in the compiler. This can decrease interaction speed. To disable the documentation tests from running use --docs=none This is similar to the flag which already skips performance tests: --skip-perf Cheers, Matt

5 4

build-system design document: how relevant is it now?
by Norman Ramsey 22 Oct '21

22 Oct '21

I'm trawling the GHC wiki looking for things that will help me understand how the build system works and what might need to change for cross-compilation. I stumbled across https://gitlab.haskell.org/ghc/ghc/-/wikis/design/build-system which git helpfully tells me dates from 2008. I assume that none of it is relevant any longer. In its current form, the page seems only likely to confuse future contributors. I'd rather not leave things that way. Does the page have archival value? Is there a directory of legacy pages to which I should move it? Or shall I just delete the current text and replace it with a short note? Or what? Norman

3 2

Gitlab
by Simon Peyton Jones 21 Oct '21

21 Oct '21

Is it just me, or is Gitlab offline again? I'm getting error code 500. 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.)

5 8