- ghc-devs - Haskell.org

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

Re: lint-submods-marge consistently failing when attempting to update Haddock
by Ryan Scott 15 Jul '19

15 Jul '19

The submodule linter appears to have been disabled in [1]. As Matthew notes in [2], perhaps we should probably open a ticket to track how to restore it. Ryan S. ----- [1] https://gitlab.haskell.org/ghc/ghc/commit/a39a3cd663273c46cf4e346ddf3bf9fb3… [2] https://gitlab.haskell.org/ghc/ghc/commit/a39a3cd663273c46cf4e346ddf3bf9fb3…

2 1

Is HEAD broken?
by Andreas Klebinger 14 Jul '19

14 Jul '19

Is HEAD broken? I get this error with hadrian: I suspect it's only broken on windows and has to do with MSYS #ifdefs /-------------------------------------------------------------------------\ | Successfully built library 'ghci' (Stage0, way v). | | Library: _build/stage0/libraries/ghci/build/libHSghci-8.9.0.20190714.a | | Library synopsis: The library supporting GHC's interactive interpreter. | \-------------------------------------------------------------------------/ | Copy package 'ghci' # cabal-copy (for _build/stage0/lib/package.conf.d/ghci-8.9.0.20190714.conf) | Register package 'ghci' # cabal-register (for _build/stage0/lib/package.conf.d/ghci-8.9.0.20190714.conf) | Run Ghc CompileHs Stage0: libraries/text/Data/Text/Internal/Encoding/Fusion/Common.hs => _build/stage0/libraries/text/build/Data/Text/Internal/Encoding/Fusion/Common.o | Run Ghc CompileHs Stage0: libraries/text/Data/Text/Show.hs => _build/stage0/libraries/text/build/Data/Text/Show.o # cabal-configure (for _build/stage0/compiler/setup-config) | Run Ghc CompileHs Stage0: libraries/text/Data/Text/Internal/Encoding/Fusion.hs => _build/stage0/libraries/text/build/Data/Text/Internal/Encoding/Fusion.o | Run Ghc CompileHs Stage0: libraries/text/Data/Text/Internal/Lazy/Encoding/Fusion.hs => _build/stage0/libraries/text/build/Data/Text/Internal/Lazy/Encoding/Fusion.o # cabal-autogen (for _build/stage0/compiler/build/autogen/cabal_macros.h) | Run GhcPkg Dependencies Stage0: process WARNING: cache is out of date: C:\ghc\msys64\opt\ghc\lib\package.conf.d\package.cache ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix. | Run GhcPkg Unregister Stage0: process => none | Run Ghc CompileHs Stage0: libraries/text/Data/Text/Encoding.hs => _build/stage0/libraries/text/build/Data/Text/Encoding.o | Run Ghc CompileHs Stage0: libraries/text/Data/Text.hs => _build/stage0/libraries/text/build/Data/Text.o | Run Ghc CompileHs Stage0: libraries/text/Data/Text/Foreign.hs => _build/stage0/libraries/text/build/Data/Text/Foreign.o ghc-pkg.exe: cannot find package process | Run GhcPkg Copy Stage0: process => _build/stage0/lib/package.conf.d/process-1.6.5.0.conf | Run Ghc CompileHs Stage0: libraries/text/Data/Text/Read.hs => _build/stage0/libraries/text/build/Data/Text/Read.o | Run Ghc CompileHs Stage0: libraries/text/Data/Text/Internal/Lazy.hs => _build/stage0/libraries/text/build/Data/Text/Internal/Lazy.o | Run Ghc CompileHs Stage0: libraries/text/Data/Text/Internal/IO.hs => _build/stage0/libraries/text/build/Data/Text/Internal/IO.o WARNING: cache is out of date: C:\ghc\msys64\opt\ghc\lib\package.conf.d\package.cache ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix. | Run Cc FindCDependencies Stage0: compiler/parser/cutils.c => _build/stage0/compiler/build/c/parser/cutils.o.d | Run Cc FindCDependencies Stage0: compiler/ghci/keepCAFsForGHCi.c => _build/stage0/compiler/build/c/ghci/keepCAFsForGHCi.o.d | Run Cc FindCDependencies Stage0: compiler/cbits/genSym.c => _build/stage0/compiler/build/c/cbits/genSym.o.d | Run DeriveConstants: none => _build/generated/DerivedConstants.h (and 1 more) | Run DeriveConstants: none => _build/generated/GHCConstantsHaskellExports.hs (and 1 more) | Run Happy: compiler/parser/Parser.y => _build/stage0/compiler/build/Parser.hs | Run DeriveConstants: none => _build/generated/GHCConstantsHaskellWrappers.hs (and 1 more) | Run Ghc CompileHs Stage0: libraries/text/Data/Text/Internal/Lazy/Search.hs => _build/stage0/libraries/text/build/Data/Text/Internal/Lazy/Search.o | Run Ghc CompileHs Stage0: libraries/text/Data/Text/Lazy/Internal.hs => _build/stage0/libraries/text/build/Data/Text/Lazy/Internal.o | Run Ghc CompileHs Stage0: libraries/text/Data/Text/Internal/Lazy/Fusion.hs => _build/stage0/libraries/text/build/Data/Text/Internal/Lazy/Fusion.o | Run Ghc CompileHs Stage0: libraries/text/Data/Text/IO.hs => _build/stage0/libraries/text/build/Data/Text/IO.o | Successfully generated _build/stage0/compiler/build/Config.hs. | Run Alex: compiler/cmm/CmmLex.x => _build/stage0/compiler/build/CmmLex.hs | Run HsCpp: compiler/prelude/primops.txt.pp => _build/stage0/compiler/build/primops.txt In file included from includes/MachDeps.h:45:0, from compiler/prelude/primops.txt.pp:122: includes/ghcautoconf.h:1:0: error: unterminated #if #if !defined(__GHCAUTOCONF_H__) Error when running Shake build system: at action, called at src\Rules.hs:68:19 in main:Rules at need, called at src\Rules.hs:90:5 in main:Rules * Depends on: _build/stage0/lib/package.conf.d/ghc-8.9.0.20190714.conf at need, called at src\Rules\Register.hs:115:5 in main:Rules.Register * Depends on: _build/stage0/compiler/build/libHSghc-8.9.0.20190714.a at need, called at src\Rules\Library.hs:144:5 in main:Rules.Library * Depends on: _build/stage0/compiler/build/TcTypeable.o at &%>, called at src\Rules\Compile.hs:47:9 in main:Rules.Compile * Depends on: _build/stage0/compiler/build/TcTypeable.o _build/stage0/compiler/build/TcTypeable.hi at apply1, called at src\Development\Shake\Internal\Rules\Oracle.hs:159:32 in shake-0.18.3-2a90fc68b337e984af1d3900d8eeed6f2bc6fa1a:Development.Shake.Internal.Rules.Oracle * Depends on: OracleQ (KeyValues ("_build/stage0/compiler/.dependencies","_build/stage0/compiler/build/TcTypeable.o")) at need, called at src\Hadrian\Oracles\TextFile.hs:96:9 in main:Hadrian.Oracles.TextFile * Depends on: _build/stage0/compiler/.dependencies at readFile', called at src\Rules\Dependencies.hs:34:19 in main:Rules.Dependencies at need, called at src\Development\Shake\Internal\Derived.hs:118:15 in shake-0.18.3-2a90fc68b337e984af1d3900d8eeed6f2bc6fa1a:Development.Shake.Internal.Derived * Depends on: _build/stage0/compiler/.dependencies.mk at need, called at src\Rules\Dependencies.hs:26:9 in main:Rules.Dependencies * Depends on: _build/stage0/compiler/build/primop-fixity.hs-incl at need, called at src\Rules\Generate.hs:147:5 in main:Rules.Generate * Depends on: _build/stage0/compiler/build/primops.txt * Raised the exception: user error (Development.Shake.cmd, system command failed Command line: E:/ghc_head/inplace/mingw/bin/gcc.exe -E -undef -traditional -P -Iincludes -I_build/generated -I_build/stage0/compiler/build -x c compiler/prelude/primops.txt.pp Exit code: 1 Stderr: In file included from includes/MachDeps.h:45:0, from compiler/prelude/primops.txt.pp:122: includes/ghcautoconf.h:1:0: error: unterminated #if #if !defined(__GHCAUTOCONF_H__)

1 1

Gitlab workflow
by Simon Peyton Jones 12 Jul '19

12 Jul '19

Ben Still trying to understand GitLab. Look at MR 1352 https://gitlab.haskell.org/ghc/ghc/merge_requests/1352 * It clearly says on the first page "The changes were not merged into master" * But lower down (at the end) it says "Merged in 80af..." What should I believe? Merged or not merged? Also * It would be really helpful if a MR status, displayed prominently at the top, had "Merged" as a status, not just "Closed". If I'm trying to check if my has landed, and I see "Closed", that could mean that someone has (doubtless for good reasons) closed it manually, and that it will never land. Would that be possible? Thanks Simon

9 17