- ghc-devs - Haskell.org

Re: [ANNOUNCE] GHC 8.2.1 release candidate 2
by Ryan Scott 26 May '17

26 May '17

Alberto, > I've manage to reproduce the CK bug without any external dependencies and > opened a ticket with an attached module that fails to compile with > 8.2.1-rc2 (w/o explicit KindSignature) but compiles fine with 8.0.2. Thanks for doing this! > Will hopefully follow up soon with the Cabal issues I'm experiencing One thing that might be useful to do is to invoke Cabal with high verbosity (e.g., -v3) and post the logs somewhere. I wouldn't be surprised if Nix was passing some uncommonly used flags that have regressed in recent versions of Cabal. Ryan S.

2 2

RE: Trees that Grow in the hsSyn AST
by David Feuer 26 May '17

26 May '17

I haven't looked in detail yet, but there seem to be good ideas. I have two questions: 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. 2. If we're making intrusive changes to representations, would now be a sensible era to consider switching to a different variable representation (unbound, bound, abt, etc)? David FeuerWell-Typed, LLP -------- Original message --------From: Simon Peyton Jones via ghc-devs <ghc-devs(a)haskell.org> Date: 5/25/17 6:48 PM (GMT-05:00) To: Alan & Kim Zimmerman <alan.zimm(a)gmail.com>, ghc-devs(a)haskell.org Subject: RE: Trees that Grow in the hsSyn AST Folks Do take a look at this: · We propose to re-engineer HsSyn itself. This will touch a lot of code. · But it’s very neat, and will bring big long-term advantages · And we can do it a bit at a time The wiki page https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow has the details. It’s entirely an internal change, not a change to GHC’s specification, so it’s independent of the GHC proposals process. But I’d value the opinion of other GHC devs. Alan has done a prototype first step, which worked out rather well. Rather than having HsExpr Id (which we all know means “HsExpr after the typechecker” but tha’s a bit inexplicit, we have HsExpr GhcTc meaning “HsExpr after GHC’s Tc pass”. In some ways this is quite superficial, but it unlocks the Trees That Grow machiney. Please ask questions etc. Alan and Shayan can record the answers in the wiki. I’m inclined to go ahead with this, so yell soon if you disagree. Simon From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Alan & Kim Zimmerman Sent: 24 May 2017 22:52 To: ghc-devs(a)haskell.org Subject: Trees that Grow in the hsSyn AST Hi all You may be aware that Shayan Najd presented the paper "Trees that Grow"[1] at HIW last year. Based on the following mandate > As in my previous email to Shayan (attached). Wiki page, describe goals, design, > approach. Point to prototype implementation. Seek comments. You can say that >I am supportive! > > Simon We have set up a Wiki page at [2] describing a prototype implementation of the first stage of this for the hsSyn AST, which is to change the polymorphic variable from one of RdrName / Name / Id to an index type. This is presented as a fabricator diff at [3]. Please take a look and provide feedback. Regards Alan [1] http://www.jucs.org/jucs_23_1/trees_that_grow/jucs_23_01_0042_0062_najd.pdf<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jucs.or…> [2] https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow [3] https://phabricator.haskell.org/D3609

2 1

Trees that Grow in the hsSyn AST
by Alan & Kim Zimmerman 25 May '17

25 May '17

Hi all You may be aware that Shayan Najd presented the paper "Trees that Grow"[1] at HIW last year. Based on the following mandate > As in my previous email to Shayan (attached). Wiki page, describe goals, design, > approach. Point to prototype implementation. Seek comments. You can say that >I am supportive! > > Simon We have set up a Wiki page at [2] describing a prototype implementation of the first stage of this for the hsSyn AST, which is to change the polymorphic variable from one of RdrName / Name / Id to an index type. This is presented as a fabricator diff at [3]. Please take a look and provide feedback. Regards Alan [1] http://www.jucs.org/jucs_23_1/trees_that_grow/jucs_23_01_0042_0062_najd.pdf [2] https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow [3] https://phabricator.haskell.org/D3609

2 1

Type class instances in scope
by Tom Sydney Kerckhove 24 May '17

24 May '17

Dear GHC Devs. I am trying to use the GHC API as part of the work that I am doing for my thesis. Currently I am looking for a way to find all the type class instances that are in scope in a given module. Here's what I've tried: ``` getInstancesFromTcmodule :: GhcMonad m => TypecheckedModule -> m () getInstancesFromTcmodule tmod = do let (tcenv, md) = tm_internals_ tmod let insts = tcg_insts tcenv getInsts >>= printO printO $ modInfoInstances $ tm_checked_module_info tmod printO insts printO $ md_insts md printO $ tcg_inst_env tcenv printO :: (GhcMonad m, Outputable a) => a -> m () printO a = showGHC a >>= (liftIO . putStrLn) ``` Unfortunately the output that I get is empty: ``` ([], []) [] [] [] [] ``` For the record, I ran this on the following module: ``` {-# LANGUAGE NoImplicitPrelude #-} module Ints where import Prelude (Int, (+), (-)) f :: Int -> Int f x = x + 1 g :: Int -> Int g x = x - 1 double :: Int -> Int double x = x + x zero :: Int zero = 0 ``` Because I'm using '+' and '-', I definitely expect the instances of 'Num' to be available, but I am also expecting to find ALL the other instances that are available for type checking. Is there any documentation on this matter? Failing that, is there anyone who is willing to help me with this problem? Thank you for your time. -- Tom Sydney Kerckhove

2 6

[ANNOUNCE] GHC 8.2.1 release candidate 2
by Ben Gamari 23 May '17

23 May '17

Hello everyone, The GHC team is very pleased to announce the second candidate of the 8.2.1 release of the Glasgow Haskell Compiler. Source and binary distributions are available at https://downloads.haskell.org/~ghc/8.2.1-rc2/ This is the second of what will likely be either two or three release candidates leading up the final 8.2.1 release. This release will feature, * A new type-indexed Typeable implementation * The long awaited Backpack * Deriving strategies for disambiguating DeriveAnyClass, GeneralizedNewtypeDeriving, and stock mechanisms * Overloaded record fields * Improved compiler performance * Better code generation through more robust tracking of join points * Compact regions for more efficient garbage collection and serialization * Better support for machines with non-uniform memory architectures * More robust support for levity (e.g. RuntimeRep) polymorphism * A simple interface for streaming eventlog data from live processes * Further refinement of DWARF support This candidate fixes most of the issues present in release candidate one including, * #13233: typePrimRep panic while compiling GHC with profiling enabled * #13509: type error involving unboxed tuples * #13426: compile-time memory-usage regression * #13560: Windows binary distributions carry absolute paths to toolchain * #13585: Control.Lens.Wrapped.ala causes compiler panic * #13623: Join points produce bad code for stream fusion As always, please let us know if you have difficulty. Thanks to everyone who has contributed! Happy testing, - Ben

4 6

8.2 and earlier build times
by Christopher Allen 22 May '17

22 May '17

I did a build time test with hackage.haskell.org/package/bloodhound today. I tested 8.2 (RC), 8.0, 7.10, and 7.8. I used Bloodhound in part because it has very few but very large modules which is sort of a pathological case for GHC right now. I first built the deps and library with each compilers and then reran the build once or twice until the results stabilized. The build re-built the V5/Types module and the examples depending on that module. I triggered a build by adding/removing newline characters in the V5/Types module. I've pushed the build targets / stack.yamls to the git repository: https://github.com/bitemyapp/bloodhound Here are the results: 8.2 build: 126.37s user 2.26s system 101% cpu 2:07.16 total 8.0 build: 147.44s user 2.24s system 100% cpu 2:28.93 total 7.10 build: 163.38s user 2.14s system 100% cpu 2:44.64 total 7.8 build: 129.12s user 2.30s system 101% cpu 2:10.09 total Please let me know if you have any questions. -- Chris Allen Currently working on http://haskellbook.com

5 7

How lose can we be with strictness
by Joachim Breitner 22 May '17

22 May '17

Hi, I just observed that GHC optimizes fun (n::Int) = n == 0 + n to essentially fun (n::Int) = n `seq` True I am wondering under what circumstances we would be happy to transform this further to fun _ = True Clearly, we do not want to drop `seq`s in general. But is there some commonly accepted rule about which strictness we generally allow the compiler to get rid of, if it turns out that the compiler can do without? Or are all such transformations out of bounds for GHC? Greetings, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

4 4

Re: [ANNOUNCE] GHC 8.2.1 release candidate 2
by Ryan Scott 22 May '17

22 May '17

Hi Alberto. Thanks for the very detailed report! > - A weird kind error when using ConstraintKinds in a propietary package > which didn't manifest itself with ghc < 8.2: > > ... > > Is this expected behaviour? > Should I try to isolate and open a ticket? This looks like a proper bug to me. Can you minimize the example a submit a bug report at https://ghc.haskell.org/trac/ghc/newticket for this? Thanks! > - I had to disable the tests for two packages since they seem to "hang" > (ie: they never finish running and don't seem to consume any CPU time). > These packages are lens-4.15.1 and fingertree-0.1.1.0. Maybe it's a Nix > environmental issue, I'm not sure. Can anyone reproduce this? The fact that the lens tests run forever sounds unusual to me, as the lens repo has been running regression tests with GHC 8.2 for a while with no observed slowdowns. I'll double-check soon just to be sure, though. However, I can confirm that the fingertree tests appear to loop forever at runtime with GHC 8.2 (as opposed to GHC 8.0, where they finish in about 7.5 seconds). This is certainly not a good thing, so I'll try to investigate this more. Thanks for noticing this. > - I can't manage to install several packages which include executables > (namely, update-nix-fetchgit and snap-server, for the moment) because Cabal > says that it cannot find the source for the main module of the executables: > > "Setup: can't find source for Main in ." > > It seems that the "hs-source-dir" directive in the .cabal file is not being > honored. Maybe a Nix-only issue? Can anyone reproduce this? Any ideas on > how can I fix it? I can't reproduce this issue, at least with update-nix-fetchgit-0.1.0.0 (by using `cabal install` to install it). Can you give more detailed instructions on how to trigger this error? Ryan S.

2 3

Getting valid substitutions to work for subsumption
by Matthías Páll Gissurarson 19 May '17

19 May '17

Greetings, I'm working on improving the valid substitution feature that I implemented a few weeks ago, but I'm having a problem making it work with subsumption, i.e. if the types are not exactly equal. You can find all the code on a branch on my fork of GHC on GitHub <https://github.com/Tritlo/ghc/tree/show-valid-substitutions-subsumes>, with the subsumption checker being the following function: -- Reports whether one type subsumes another, discarding any errors tcSubsumes :: TcSigmaType -> TcSigmaType -> TcM Bool tcSubsumes hole_ty ty = discardErrs $ do { (_, wanted, _) <- pushLevelAndCaptureConstraints $ tcSubType_NC ExprSigCtxt ty hole_ty ; (rem, _) <- runTcS (simpl_top wanted) ; return (isEmptyWC rem) } The current example I'm working with is module T3 where ps3 :: Num a => a -> a -> a ps3 = (+) ps4 :: Num a => a -> a -> a ps4 = _ Which should of course include (+) as a suggestion. However, when it checks for (+), it does not report it as a match. What could be going wrong here? Could someone more familiar with the underlying machinery give some guidance on what could be going wrong here? Dumping the traceTc (i.e. running ./inplace/bin/ghc-stage2 -o test t3.hs -ddump-tc-trace) gives the following relevant output in the dump: Checking for substitution + parent:Num imported from ‘Prelude’ at t3.hs:1:8-9 (and originally defined in ‘GHC.Num’) tcSubType_NC an expression type signature forall a. Num a => a -> a -> a a_a1D1[sk:2] -> a_a1D1[sk:2] -> a_a1D1[sk:2] tc_sub_tc_type (general case) ty_actual = forall a. Num a => a -> a -> a ty_expected = a_a1D1[sk:2] -> a_a1D1[sk:2] -> a_a1D1[sk:2] tcSkolemise tc_sub_type_ds ty_actual = forall a. Num a => a -> a -> a ty_expected = a_a1D1[sk:2] -> a_a1D1[sk:2] -> a_a1D1[sk:2] instCallConstraints [$dNum_a4eI] Instantiating all tyvars? True origin arising from a type equality forall a. Num a => a -> a -> a ~ a_a1D1[sk:2] -> a_a1D1[sk:2] -> a_a1D1[sk:2] type forall a. Num a => a -> a -> a theta [Num a_a19t] leave_bndrs [] with [a_a4eH[tau:3]] theta: [Num a0_a4eH[tau:3]] tc_sub_type_ds ty_actual = a0_a4eH[tau:3] -> a0_a4eH[tau:3] -> a0_a4eH[tau:3] ty_expected = a_a1D1[sk:2] -> a_a1D1[sk:2] -> a_a1D1[sk:2] tc_sub_type_ds ty_actual = a0_a4eH[tau:3] -> a0_a4eH[tau:3] ty_expected = a_a1D1[sk:2] -> a_a1D1[sk:2] tc_sub_type_ds ty_actual = a0_a4eH[tau:3] ty_expected = a_a1D1[sk:2] u_tys tclvl 3 a0_a4eH[tau:3] ~ a_a1D1[sk:2] arising from a type equality a0_a4eH[tau:3] -> a0_a4eH[tau:3] -> a0_a4eH[tau:3] ~ a_a1D1[sk:2] -> a_a1D1[sk:2] -> a_a1D1[sk:2] u_tys tclvl 3 * ~ * arising from a kind equality arising from a0_a4eH[tau:3] ~ a_a1D1[sk:2] u_tys tclvl 3 'GHC.Types.LiftedRep ~ 'GHC.Types.LiftedRep arising from a kind equality arising from a0_a4eH[tau:3] ~ a_a1D1[sk:2] u_tys yields no coercion u_tys yields no coercion writeMetaTyVar a_a4eH[tau:3] :: * := a_a1D1[sk:2] u_tys yields no coercion tc_sub_tc_type (general case) ty_actual = a_a1D1[sk:2] ty_expected = a0_a4eH[tau:3] tcSkolemise tc_sub_type_ds ty_actual = a_a1D1[sk:2] ty_expected = a0_a4eH[tau:3] u_tys tclvl 3 a_a1D1[sk:2] ~ a0_a4eH[tau:3] arising from a type equality a0_a4eH[tau:3] -> a0_a4eH[tau:3] -> a0_a4eH[tau:3] ~ a_a1D1[sk:2] -> a_a1D1[sk:2] -> a_a1D1[sk:2] u_tys yields no coercion tc_sub_tc_type (general case) ty_actual = a_a1D1[sk:2] ty_expected = a0_a4eH[tau:3] tcSkolemise tc_sub_type_ds ty_actual = a_a1D1[sk:2] ty_expected = a0_a4eH[tau:3] u_tys tclvl 3 a_a1D1[sk:2] ~ a0_a4eH[tau:3] arising from a type equality a0_a4eH[tau:3] -> a0_a4eH[tau:3] -> a0_a4eH[tau:3] ~ a_a1D1[sk:2] -> a_a1D1[sk:2] -> a_a1D1[sk:2] u_tys yields no coercion newTcEvBinds unique = a4eJ solveWanteds { WC {wc_simple = [WD] $dNum_a4eI {0}:: Num a0_a4eH[tau:3] (CNonCanonical)} solveSimpleWanteds { {[WD] $dNum_a4eI {0}:: Num a0_a4eH[tau:3] (CNonCanonical)} ----------------------------- Start solver pipeline { work item = [WD] $dNum_a4eI {0}:: Num a0_a4eH[tau:3] (CNonCanonical) inerts = {Unsolved goals = 0} rest of worklist = WL {} runStage canonicalization { workitem = [WD] $dNum_a4eI {0}:: Num a0_a4eH[tau:3] (CNonCanonical) canonicalize (non-canonical) [WD] $dNum_a4eI {0}:: Num a0_a4eH[tau:3] (CNonCanonical) canEvNC:cls Num [a0_a4eH[tau:3]] flatten_many { a0_a4eH[tau:3] Following filled tyvar a_a4eH[tau:3] = a_a1D1[sk:2] Unfilled tyvar a_a1D1[sk:2] flatten } a_a1D1[sk:2] canClass [WD] $dNum_a4eI {0}:: Num a0_a4eH[tau:3] Num a_a1D1[sk:2] ContinueWith [WD] $dNum_a4eI {0}:: Num a_a1D1[sk:2] end stage canonicalization } runStage interact with inerts { workitem = [WD] $dNum_a4eI {0}:: Num a_a1D1[sk:2] (CDictCan) end stage interact with inerts } runStage top-level reactions { workitem = [WD] $dNum_a4eI {0}:: Num a_a1D1[sk:2] (CDictCan) doTopReact [WD] $dNum_a4eI {0}:: Num a_a1D1[sk:2] (CDictCan) matchClassInst pred = Num a_a1D1[sk:2] { matchClass not matching dict Num a_a1D1[sk:2] } matchClassInst result NoInstance try_fundeps [WD] $dNum_a4eI {0}:: Num a_a1D1[sk:2] (CDictCan) end stage top-level reactions } insertInertCan { Trying to insert new non-eq inert item: [WD] $dNum_a4eI {0}:: Num a_a1D1[sk:2] (CDictCan) addInertCan } Step 1[l:2,d:0] Kept as inert: [WD] $dNum_a4eI {0}:: Num a_a1D1[sk:2] End solver pipeline (kept as inert) } final_item = [WD] $dNum_a4eI {0}:: Num a_a1D1[sk:2] (CDictCan) getUnsolvedInerts tv eqs = {} fun eqs = {} insols = {} others = {[WD] $dNum_a4eI {0}:: Num a_a1D1[sk:2] (CDictCan)} implics = {} Unflattening {Funeqs = Tv eqs =} Unflattening 1 {} Unflattening 2 {} Unflattening 3 {} Unflattening done {} zonkSimples done: {} solveSimpleWanteds end } iterations = 1 residual = WC {wc_simple = [WD] $dNum_a4eI {0}:: Num a_a1D1[sk:2] (CDictCan)} expandSuperClasses { End expandSuperClasses no-op } solveWanteds middle simples1 = {[WD] $dNum_a4eI {0}:: Num a_a1D1[sk:2] (CDictCan)} simples2 = {[WD] $dNum_a4eI {0}:: Num a_a1D1[sk:2] (CDictCan)} solveWanteds } final wc = WC {wc_simple = [WD] $dNum_a4eI {0}:: Num a_a1D1[sk:2] (CDictCan)} current evbinds = {} zonkSimples done: {[WD] $dNum_a4eI {0}:: Num a_a1D1[sk:2] (CDictCan(psc))} zonkSimples done: {} applyDefaultingRules { wanteds = WC {wc_simple = [WD] $dNum_a4eI {0}:: Num a_a1D1[sk:2] (CDictCan(psc))} groups = [] info = ([Integer, Double], (False, False)) applyDefaultingRules } [] Constraint solver steps = 1 -- Matthías Páll Gissurarson

3 3

Type families and classes
by Alan & Kim Zimmerman 18 May '17

18 May '17

Hi all I am experimenting with Trees that Grow [1] in the context of the GHC HsSyn AST, and wanting to express that a given extension point needs to have certain properties. The specific case is to be able to contain a SourceText, in the context of HsLit So I have (stripped down) data GHCX type family XHsString x type instance XHsString GHCX = SourceText class HasSourceText a where -- Provide setters to mimic existing constructors noSourceText :: a sourceText :: String -> a getSourceText :: a -> SourceText instance HasSourceText (XHsString GHCX) where noSourceText = NoSourceText sourceText s = SourceText s getSourceText a = a But this gives an error compiler/hsSyn/HsExtension.hs:80:10: error: • Illegal type synonym family application in instance: XHsString GHCX • In the instance declaration for ‘HasSourceText (XHsString GHCX)’ Is there some way to achieve this, or is it simply impossible? The full work-in-progress source is here[2] Regards Alan [1] https://arxiv.org/abs/1610.04799 [2] https://github.com/alanz/ghc/blob/df1c3b3d42284dd121086e6c571793f19e758977/…

2 2