- ghc-devs - Haskell.org

Distributed local dev builds
by Julian Leviston 17 Feb '19

17 Feb '19

Hi all, I have several fairly high-spec machines on my network where I usually build GHC, and I was wondering if it was easy/trivial/possible to set up a distributed build where it farmed out some of the compute work to the other machines? I seem to need to build from scratch somewhat often when I switch branches I’m working on. Is this going to be the aim of distributed shake, which hadrian is based on? Thanks! Julian

1 0

Re: scopedSort and kind variable left-biasing
by Ryan Scott 15 Feb '19

15 Feb '19

As Vlad notes in [1], getting rid of FreeKiTyVars isn't as simple as it would appear, as we still treat kinds and types differently in other places, such as data type declarations. For instance: data Proxy (a :: k) = Proxy -- k is brought into scope implicitly by `extractDataDefnKindVars` I don't know how to overcome this awkwardness, so if you have suggestions, please comment at [1]. Ryan S. ----- [1] https://gitlab.haskell.org/ghc/ghc/merge_requests/361#note_6709

1 0

Is this the correct way to get Stg for a module?
by Christopher Done 15 Feb '19

15 Feb '19

Hi all, I'm attempting to get the Stg for a module with the intention of interpreting it myself. Here is a self-contained GHC-8.4.3-specific test-case to get STG: https://gist.github.com/chrisdone/08ef9e8447b71c9dadc5bba949cda638#file-pri… I'm using the handy helpers GHC.parseModule, GHC.typecheckModule, GHC.desugarModule to get the Core. For getting the STG I copied what is done in HscMain.hs in GHC, right before it generates Cmm: https://github.com/ghc/ghc/blob/ghc-8.4/compiler/main/HscMain.hs#L1312-L1318 Can anyone confirm that the part I've highlighted in my Gist is the correct way to get Stg? I can't really tell whether I missed anything or did something wrong. Cheers!

1 0

typecheck/should_fail/all.T
by Simon Peyton Jones 15 Feb '19

15 Feb '19

There's a mysterious line 4607 at the top of testsuite/tests/typecheck/should_fail/all.T Should it be there? What does it do? Could it be bad? Simon

2 2

scopedSort and kind variable left-biasing
by Ryan Scott 14 Feb '19

14 Feb '19

Consider this function: f :: Proxy (a :: j) -> Proxy (b :: k) If you just collect the free type variables of `f`'s type in left-to-right order, you'd be left with [a,j,b,k]. But the type of `f` is not `forall (a :: j) j (b :: k) k. Proxy a -> Proxy b`, as that would be ill scoped. `j` must come before `a`, since `j` appears in `a`'s kind, and similarly, `k` must come before `b`. Fortunately, GHC is quite smart about sorting free variables such that they respect dependency order. If you ask GHCi what the type of `f` is (with -fprint-explicit-foralls enabled), it will tell you this: λ> :type +v f f :: forall j k (a :: j) (b :: k). Proxy a -> Proxy b As expected, `j` appears before `a`, and `k` appears before `b`. In a different context, I've been trying to implement a type variable sorting algorithm similar to the one that GHC is using. My previous understanding was that the entirely of this sorting algorithm was implemented in `Type.scopedSort`. To test my understanding, I decided to write a program using the GHC API which directly uses `scopedSort` on the example above: main :: IO () main = do let tv :: String -> Int -> Type -> TyVar tv n uniq ty = mkTyVar (mkSystemName (mkUniqueGrimily uniq) (mkTyVarOcc n)) ty j = tv "j" 0 liftedTypeKind a = tv "a" 1 (TyVarTy j) k = tv "k" 2 liftedTypeKind b = tv "b" 3 (TyVarTy k) sorted = scopedSort [a, j, b, k] putStrLn $ showSDocUnsafe $ ppr sorted To my surprise, however, running this program does /not/ give the answer [j,k,a,b], like what :type reported: λ> main [j_0, a_1, k_2, b_3] Instead, it gives the answer [j,a,k,b]! Strictly speaking, this answer meets the specification of ScopedSort, since it respects dependency order and preserves the left-to-right ordering of variables that don't depend on each other (i.e., `j` appears to the left of `k`, and `a` appears to the left of `b`). But it's noticeably different that what :type reports. The order that :type reports, [j,k,a,b], appears to bias kind variables to the left such that all kind variables (`j` and `k`) appear before any type variables (`a` and `b`). >From what I can tell, scopedSort isn't the full story here. That is, something else appears to be left-biasing the kind variables. My question is: which part of GHC is doing this left-biasing? Ryan S.

3 8

Re: Performance of pattern synonyms
by Carter Schonwald 14 Feb '19

14 Feb '19

Hey Matthew, One dimension of analsysis that would be instructive would be to characterize the differences in core / stg for these different versions Also : am I correct in believing that these all are the exact same algorithm in terms of representation or am I overlooking some differences between the 3 different codes ? On Mon, Feb 11, 2019 at 4:07 PM Matthew Roberts <matthew.roberts(a)mq.edu.au> wrote: > My apologies, > > The link to the source was broken by some repo work - I have fixed it and > it should be stable now. This page was intended just to be a way of > showing the results to my collaborators, not a full explanation that anyone > can follow, but I thought the graphs at least show off what I am seeing. > > Regardless, it is all there in the code and hopefully not too obtuse. I > can improve the discussion on the page if enough people are interested :) > > Matt > > On 12 Feb 2019, at 5:14 AM, Carter Schonwald <carter.schonwald(a)gmail.com> > wrote: > > I'm looking at these links, but i'm actually having a hard time finding > the actual different definitions of this microbenchmark... > > On Mon, Feb 11, 2019 at 9:22 AM Richard Eisenberg <rae(a)cs.brynmawr.edu> > wrote: > >> >> >> On Feb 11, 2019, at 8:55 AM, Simon Peyton Jones <simonpj(a)microsoft.com> >> wrote: >> >> What exactly is “the alternative compile-time implementation”? >> >> >> In my response, I interpreted this to be macro-expansion, the alternative >> we discuss in the paper. The paper includes a nice discussion of how the >> semantics differs between what we currently have and macro-expansion. >> >> Richard >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs(a)haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> <https://protect-au.mimecast.com/s/DjjUCK1DOrC8NwxohMgjBd?domain=mail.haskel…> >> > >

1 0

Marge has been stabilised
by Matthew Pickering 13 Feb '19

13 Feb '19

Hi all, I think I have finally managed to stablise the merge bot (Marge). If you have a patch ready to merge then 1. Make sure that CI shows as passing 2. Make sure it has been approved by at least one person 3. Make sure it is not marked as WIP Once these three conditions are met, assign the PR to "Marge Bot" and then she will pick it up and merge it, hopefully within 24 hours depending on her current state. Any more questions, feel free to ask. I included some more specific detail below. Cheers, Matt ------ Here is her current mode of operation. Every 30 minutes whilst idle she will try to find new MRs to batch together. If she finds at least two MRs to batch together then she creates a batch as a new merge request. A batch is the series of MRs rebased on top of each other from oldest to newest. She then waits for this merge request to pass CI, checking every 10 minutes to see if it has done so. Once the MR has passed CI, she rebases and merges each MR in the batch one by one to the target branch. In between each MR she merges she waits 5 minutes. Due to the fact each MR is merged one by one: 1. The original MR will be closed automatically. 2. A CI job will trigger for each MR as it lands on master.

4 10

Re: TTG: Handling Source Locations
by Ryan Scott 13 Feb '19

13 Feb '19

Yes, I agree. This will require sprinkling the codebase with EmptyCase due to [1], but that's still a sight better than calling `panic`. After GHC 8.10 is released (and the minimum version of GHC that HEAD supports is 8.8), we can even remove these empty cases by making the empty data type fields strict (see [2]). Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/ticket/15247#comment:4 [2] https://ghc.haskell.org/trac/ghc/ticket/15305

2 2

Re: TTG: Handling Source Locations
by Ryan Scott 13 Feb '19

13 Feb '19

> Yes, I have reported it while back. I don't know of the progress in fixing this. Reported what? #15884? [1] You do realize that there is a very simple workaround for that issue, right? Instead of writing this, which is subject to the pattern-guard completeness issues observed in #15753: f :: Maybe a -> Bool f (id->Nothing) = False f (id->(Just _)) = True You can instead write this: f :: Maybe a -> Bool f (id -> x) = case x of Nothing -> False Just _ -> True This will get proper coverage checking, which means that this technique could be used to remove all of the panicking catch-all cases brought about by dL view patterns. Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/ticket/15884 [2] https://ghc.haskell.org/trac/ghc/ticket/15753

1 0

TTG: Handling Source Locations
by Richard Eisenberg 12 Feb '19

12 Feb '19

Hi devs, I just came across [TTG: Handling Source Locations], as I was poking around in RdrHsSyn and found wondrous things like (dL->L wiz waz) all over the place. General outline: https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/HandlingSou… <https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/HandlingSou…> Phab diff: https://phabricator.haskell.org/D5036 <https://phabricator.haskell.org/D5036> Trac ticket: https://ghc.haskell.org/trac/ghc/ticket/15495 <https://ghc.haskell.org/trac/ghc/ticket/15495> Commit: https://gitlab.haskell.org/ghc/ghc/commit/509d5be69c7507ba5d0a5f39ffd1613a5… <https://gitlab.haskell.org/ghc/ghc/commit/509d5be69c7507ba5d0a5f39ffd1613a5…> I see why this change is wanted and how the new version works. It seems to me, though, that this move makes us *less typed*. That is, it would be very easy (and disastrous) to forget to match on a location node. For example, I can now do this: > foo :: LPat p -> ... > foo (VarPat ...) = ... Note that I have declared that foo takes a located pat, but then I forgot to extract the location with dL. This would type-check, but it would fail. Previously, the type checker would ensure that I didn't forget to match on the L constructor. This error would get caught after some poking about, because foo just wouldn't work. However, worse, we might forget to *add* a location when downstream functions expect one. This would be harder to detect, for two reasons: 1. The problem is caught at deconstruction, and figuring out where an object was constructed can be quite hard. 2. The problem might silently cause trouble, because dL won't actually fail on a node missing a location -- it just gives noSrcSpan. So the problem would manifest as a subtle degradation in the quality of an error message, perhaps not caught until several patches (or years!) later. So I'm uncomfortable with this direction of travel. Has this aspect of this design been brought up before? I have to say I don't have a great solution to suggest. Perhaps the best I can think of is to make Located a type family. It would branch on the type index to HsSyn types, introducing a Located node for GhcPass but not for other types. This Isn't really all that extensible (I think) and it gives special status to GHC's usage of the AST. But it seems to solve the immediate problems without the downside above. Sorry for reopening something that has already been debated, but (unless I'm missing something) the current state of affairs seems like a potential wellspring of subtle bugs. Thanks, Richard

6 11