July 2019 - ghc-devs - Haskell.org

How do Coercions work
by Jan van Brügge 22 Jul '19

22 Jul '19

Hi, currently I have some problems understanding how the coercions are threaded through the compiler. In particular the function `normalise_type`. With guessing and looking at the other cases, I came to this solution, but I have no idea if I am on the right track: normalise_type ty = go ty where go (RowTy k v flds) = do { (co_k, nty_k) <- go k ; (co_v, nty_v) <- go v ; let (a, b) = unzip flds ; (co_a, ntys_a) <- foldM foldCo (co_k, []) a ; (co_b, ntys_b) <- foldM foldCo (co_v, []) b ; return (co_a `mkTransCo` co_b, mkRowTy nty_k nty_v $ zip ntys_a ntys_b) } where foldCo (co, tys) t = go t >>= \(c, nt) -> return (co `mkTransCo` c, nt:tys) RowTy has type Type -> Type -> [(Type, Type)] What I am not sure at all is how to treat the coecions. From looking at the go_app_tys code I guessed that I can just combine them like that, but what does that mean from a semantic standpoint? The core spec was not that helpful either in that regard. Thanks in advance Jan

3 5

GHC native bootstrap
by Igor Chudov 22 Jul '19

22 Jul '19

Hello! I want to bootstrap GHC on an exotic architecture and I have GCC-compatible compiler but miss cross-compiling toolchain. I was able to bootstrap Hugs98 (with manual fixes) and guys on IRC channel pointed me to GHC bootstrap articles: - https://elephly.net/posts/2017-01-09-bootstrapping-haskell-part-1.html - http://www.joachim-breitner.de/blog/748-Thoughts_on_bootstrapping_GHC which I read and plan to give it a try. I also read articles about cross-compiling GHC on Haskell wiki but the problem is complex so I don't know where to start. Are there anyone who has experience with GHC compiling (cross-compiling?) and bootstrap on new architectures who could possibly help me to solve the problem or describe the steps needed? -- With best regards, Igor Chudov

4 4

head.hackage upstream
by Ben Gamari 22 Jul '19

22 Jul '19

Hi everyone, As I noted just a moment ago in another thread on this list, head.hackage's upstream repository will be moving to GitLab. I'll but publishing a blog post soon describing some of the infrastructure we have built around head.hackage. Otherwise, if you want to submit a patch to head.hackage please open a merge request against the GitLab repository [1]. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/head.hackage

1 0

Moving head.hackage upstream
by Ben Gamari 22 Jul '19

22 Jul '19

Hi Herbert, Last week I did some work to clean up and document GHC's head.hackage infrastructure. At this point we have a full CI pipeline, including automatic deployment of a Hackage repository. I asked on #ghc and there was quite some appetite to use gitlab.haskell.org:ghc/head.hackage as the head.hackage upstream repository to eliminate confusion and enjoy the benefits of having merge requests checked via CI. Moreover, this would significantly simplify the process of testing GHC against head.hackage as it would eliminate the need to pull from a separate upstream repository. Would you be okay with moving head.hackage's upstream? Thanks again for everything you have done in the head.hackage area. Cheers, - Ben

1 3

Re: Guarded Impredicativity
by Ryan Scott 22 Jul '19

22 Jul '19

I have another interesting application of guarded impredicativity that I want to bring up. Currently, GHC #16140 [1] makes it rather inconvenient to use quantified constraints in type synonyms. For instance, GHC rejects the following example by default: type F f = (Functor f, forall a. Eq (f a)) This is because F is a synonym for a constraint tuple, so mentioning a quantified constraint in one of its arguments gets flagged as impredicative. In the discussion for #16140, we have pondered doing a major rewrite of the code in TcValidity to permit F. But perhaps we don't need to! After all, the quantified constraint in the example above appears directly underneath a type constructor (namely, the type constructor for the constraint 2-tuple), which should be a textbook case of guarded impredicativity. I don't have the guarded impredicativity branch built locally, so I am unable to test if this hypothesis is true. In any case, I wanted to mention it as another motivating use case. Ryan S. ----- [1] https://gitlab.haskell.org/ghc/ghc/issues/16140

3 3

gitlab sometimes slow
by Richard Eisenberg 18 Jul '19

18 Jul '19

Hi all, GitLab is sometimes a bit slow. I understand we host this ourselves, and faster is more expensive. My question: how much more expensive? That is, if we throw $100 at the problem, will gitlab be speedy? Will it take $1,000? $10,000? If it's the first one, then let's just blast ahead. If it's not, perhaps knowing what it would take would either help me accept the status quo (I know that every time my page loads slowly, the Haskell community has saved several dollars) or we could contemplate chipping in somehow. Thanks! Richard

4 4

Upgrading GitLab
by Ben Gamari 17 Jul '19

17 Jul '19

Hello everyone, In a moment I'm going to perform an upgrade of GitLab. I expect this will only take around 20 minutes. Cheers, - Ben

1 1

What's preventing inlining GHC.Magic.lazy?
by Ömer Sinan Ağacan 17 Jul '19

17 Jul '19

Hi Simon, I'm trying to understand what's preventing inlining GHC.Magic.lazy. I can see with -ddump-simpl -ddump-simpl-iterations -ddump-prep that we only eliminate it in CorePrep, so it's preserved during simplifications and tidying, but I don't see how. It doesn't have a NOINLINE pragma, and we don't check whether the id we're inlining is lazyId (using MkId.lazyId or MkId.lazyIdKey) anywhere in the compiler as far as I can see. I also checked Note [lazyId magic] in MkId, but it doesn't explain how we avoid inlining it. Could you say a few words on this? Thanks Ömer

3 3

Guarded Impredicativity
by Oliver Charles 16 Jul '19

16 Jul '19

Hi Alejandro and other GHC devs, I've just been pointed to this mailing list, and in particular the discussion on guarded impredicativity from the Haskell IRC channel. I wasn't following the list before, so sorry if this post comes out of threads! I have a use case for impredicative polymorphism at the moment that comes out of some work on effect systems. Essentially, what I'm trying to do is to use reflection to thread around the interpretation of an effect. One encoding of effects is: newtype Program signature carrier a = Program { ( forall x. signature x -> carrier x ) -> carrier a } But for various reasons, this sucks for writing really high performant code. My formulation is instead to change that -> to =>, and to carry around the signature interpretation with reflection. Thus we have something roughly along the lines of: newtype Program s signature carrier a = Program ( forall m. Monad m => m a ) with runProgram :: ( forall s. Reifies s ( signature :~> carrier ) => Program s signature carrier a ) -> carrier a All is well and good, but from the user's perspective, it sucks to actually compose these things together, due to the `forall s` bit. For example, I can write: foo = runError (runState s myProgram) but I can't write foo = runError . runState s $ myProgram or foo = myProgram & runState s & runError I was excited to hear there is a branch with some progress on GI, but unfortunately it doesn't seem sufficient for my application. I've uploaded everything (it's just two files) here: https://gist.github.com/ocharles/8008bf31c70d0190ff3440f9a5b0684d Currently this doesn't compile, but I'd like it to (I'm using the `nix run` command mpickering shared earlier). The problem is Example.hs:55 - if you change the first . to a $, it type checks. Let me know if this is unclear and I'm happy to refine it. I just wanted to show you: * Roughly what I want to do * A concrete program that still fails to type check, even though I believe it should (in some ideal type checker...) Regards, Ollie

2 1

Re: Moving head.hackage upstream
by Ryan Scott 15 Jul '19

15 Jul '19

Count me among the people who are eagerly awaiting this move. If I understood Ben correctly when discussing this idea with him on #ghc, then one of the benefits of having head.hackage on GitLab would be that the head.hackage index would automatically regenerate any time a commit lands. This would make things far more streamlined than the status quo, where the index has to be regenerated by hand. If head.hackage is migrated over to GitLab, would that change how people are expected to use it? That is, would it still be as simple as copying the repository stanza from [1] into one's cabal.project file? Or would that change with a move to GitLab? Ryan S. ----- [1] http://head.hackage.haskell.org/

2 1