May 2019 - ghc-devs - Haskell.org

make fails with "No entry for "integer library" in .../inplace/lib/settings"
by Roland Senn 21 May '19

21 May '19

Hi, Suddenly I'm unable to build ghc with make. I get the error: "inplace/bin/ghc-cabal" check libraries/ghc-prim "inplace/bin/ghc-cabal" configure libraries/ghc-prim dist-install -- with-ghc="/home/roland/Projekte/ghc/inplace/bin/ghc-stage1" --with-ghc- pkg="/home/roland/Projekte/ghc/inplace/bin/ghc-pkg" --disable-library- for-ghci --enable-library-vanilla --enable-library-for-ghci --disable- library-profiling --enable-shared --configure-option=CFLAGS="- Wall -Werror=unused-but-set-variable -Wno-error=inline" -- configure-option=LDFLAGS=" " --configure-option=CPPFLAGS=" " --gcc- options="-Wall -Werror=unused-but-set-variable -Wno- error=inline " --with-gcc="gcc" --with-ld="ld.gold" --with-ar="ar" -- with-alex="/home/roland/Software/ghc/bin/alex" --with- happy="/home/roland/Software/ghc/bin/happy" Configuring ghc-prim-0.6.1... ghc-cabal: '/home/roland/Projekte/ghc/inplace/bin/ghc-stage1' exited with an error: No entry for "integer library" in "/home/roland/Projekte/ghc/inplace/lib/settings" libraries/ghc-prim/ghc.mk:4: die Regel für Ziel „libraries/ghc- prim/dist-install/package-data.mk“ scheiterte make[1]: *** [libraries/ghc-prim/dist-install/package-data.mk] Fehler 1 Makefile:123: die Regel für Ziel „all“ scheiterte make: *** [all] Fehler 2 Any ideas what's wrong? Any ideas how to fix? Many thanks and best wishes Roland PS: I still need the old make based build system to run validations...

2 1

Re: Bug or feature?
by Ryan Scott 21 May '19

21 May '19

Hi Iavor, This is a feature in the sense that it is an expected outcome of the OutsideIn(X) type inference algorithm (in particular, Section 5 of the corresponding paper [1]). I'll try to explain the issue to the best of my understanding. The tricky thing about the Q3 data type: data Q3 = forall a. Q3 (forall b. (F b ~ Int) => T a b) Is that there is a rank-n type with a /local/ equality constraint. In order to ensure that the type of the Q3 data constructor is never ambiguous, GHC tries to infer that Q3's type is always a subtype of itself. As a part of this, GHC attempts to solve the following implication constraint: forall a. forall b. (F b ~ Int) => (a ~ alpha) Where `alpha` is a unification variable. GHC tries to find a unique, most-general substitution that solves this constraint but ultimately gives up and reports the "untouchable" error message you observed. This is a bit strange, however. Upon first glance, this constraint would appear to have a unique solution: namely, [alpha |-> a]. Why doesn't GHC just use this? Ultimately, it's because OutsideIn(X) is conservative: there may exist constraints that admit a unique solution which it may fail to solve. This is explained in greater depth in Section 5.2 of the paper, but the essence of this restriction is because of the open-world assumption for type families. Namely, it's possible that your Q3 data type might later be linked against code which defines the following type family: type family G i a type instance G Int a = a If that were the case, then the implication constraint above would no longer have a unique solution, since there would exist another substitution [alpha |-> G (F b) a] that is incomparable with [alpha |-> a]. OutsideIn(X) was designed to only pick unique solutions that remain unique solutions even if more axioms (i.e., type family equations) are added, so for these reasons it fails to solve the implication constraint above. See also GHC issues #10651 [2], #14921 [3], and #15649 [4], which all involve similar issues. ----- I'm far from an expert on type inference, so I can't really offer a better inference algorithm that would avoid this problem. The best you can do, as far as I can tell, is to enable AllowAmbiguousTypes and hope for the best. Even then, you'll still run into situations where untouchability rears its ugly head, as in your `q3` definition. When that happens, your only available option (again, as far as I can tell) is to make use of TypeApplications. For example, the following /does/ typecheck: q3 :: Q3 q3 = Q3 @Bool t Hope that helps, Ryan S. ----- [1] https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/jfp-out… [2] https://gitlab.haskell.org/ghc/ghc/issues/10651 [3] https://gitlab.haskell.org/ghc/ghc/issues/14921 [4] https://gitlab.haskell.org/ghc/ghc/issues/15649

4 4

Re: gitlab upgrade - change in approval system
by Ryan Scott 18 May '19

18 May '19

To be clear, your workaround is precisely what I used to do, but that is no longer working after the GitLab upgrade. I can add myself as a reviewer, but only to a group besides the default approvers list. Because Marge only counts approvals from those who belong to the default approvers list, my approvals don't count anymore. Ryan S.

1 0

Re: gitlab upgrade - change in approval system
by Ryan Scott 17 May '19

17 May '19

I would definitely appreciate changing Marge's behavior back to the old one. As things stand currently, I am unable to approve anything that I'm not explicitly listed as a reviewer for. See here [1] for an example of where this has happened. Ryan S. ----- [1] https://gitlab.haskell.org/ghc/ghc/merge_requests/559#note_198714

2 1

Bug or feature?
by Iavor Diatchki 17 May '19

17 May '19

Hello, I've encountered some odd behavior related to quantification and type families, but I am not sure if it is a bug or by design. Here is an example which works fine: > {-# Language ExistentialQuantification, RankNTypes, TypeFamilies #-} > > data T a b = T a > > t :: T Bool a > t = T True > > data Q1 = forall a. Q1 (forall b. T a b) > > q1 :: Q1 > q1 = Q1 t Now, suppose we wanted to constraint the universally quantified type of the field. This also works fine: > data Q2 = forall a. Q2 (forall b. (b ~ Int) => T a b) > > q2 :: Q2 > q2 = Q2 t However, things break down if the restriction involves a type family: > type family F a > > data Q3 = forall a. Q3 (forall b. (F b ~ Int) => T a b) > > q3 :: Q3 > q3 = Q3 t This causes some complaints about *a*, resulting from checking ambiguity. If we `AllowAmbiguousTypes`, then the definition of `Q3` is accepted, but `q3` fails with a similar error, complaining that GHC cannot match `a` with `Bool` because it is "untouchable". This seems confusing---I would have thought that when we use the `Q3` constructor we are providing the value for `a` (e.g., it is `Bool`), so I am not sure why GHC is trying to match anything. Any ideas? -Iavor

1 0

gitlab upgrade - change in approval system
by Matthew Pickering 17 May '19

17 May '19

Hi, I just noticed that the gitlab upgrade has caused the approval system to change. Before all that was required was 1 approval from anyone. Now, at least one approval from the default group is required (me, Ben, Omer, Tobias, David) I couldn't see a way to turn back to the old behaviour from a brief look at the UI. Do you know if there is a way Ben? Cheers, Matt

1 0

How to contribute a patch
by Simon Peyton Jones 16 May '19

16 May '19

Ben The "how to contribute a patch" page https://gitlab.haskell.org/ghc/ghc/wikis/working-conventions/fixing-bugs doesn't say anything about the process of actually getting it committed, notably: * Picking approvers * Assigning to Marge * Monitoring progress if it doesn't land within 24 hrs; even knowing when to time out would help. There's a bit of info, rather oddly, on the GHC wiki root page https://gitlab.haskell.org/ghc/ghc/wikis/home The initial stuff about opening a MR is details, but there is not enough on these latter steps I think. I'm cc'ing Sandy He's asking "what next"<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.ha…> and I wanted to say "look at the instructions here" but failed to find a suitable "here." Thanks Simon

3 2

GHC API, GHCi, profiling, shared objects
by Matthew Pickering 16 May '19

16 May '19

Hi, If I write a program using the GHC API then the resulting executable is sensitive to the version of GHC which I used to build the program. For example, if I build a version of GHC which has profiling enabled (prof flavour) then building my application (static linking) with this version means that I can only load packages which were also built with profiling enabled. This happens in particular when you load a module which uses TemplateHaskell which causes all the dependencies to be loaded. If the so isn't built with profiling then you get errors such as ``` <command line>: can't load .so/.DLL for: libHSblaze-html-0.9.1.1-E0enfQtU1ZTDNQ8G8pIpJp.dylib (dlopen(libHSblaze-html-0.9.1.1-E0enfQtU1ZTDNQ8G8pIpJp.dylib, 5): image not found) ``` This seemed to somewhat make sense to me because compiling with/without profiling changes the heap representation but then I considered whether this also happens in GHCi and I concluded that it didn't. In particular, it seems to me that 1. GHCi is not built by a profiled version of GHC and is still a "GHC API application" 2. There is no problem loading profiled packages into GHCi despite this fact? 1. Does GHCi do something special to mitigate against these kinds of failures? 2. Is this a difference between staticly and dynamically linking the application executable (`ghc` in the case for ghci). ? Hopefully someone familiar with the implementation of the linker will be able to clear this up. Cheers, Matt

1 1

clarification re Note [Deeper level on the left]
by Nicolas Frisby 16 May '19

16 May '19

https://gitlab.haskell.org/ghc/ghc/blob/master/compiler/typecheck/TcUnify.h… contains ``` Note [Deeper level on the left]~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~The most important thing is that we want to put tyvars withthe deepest level on the left. The reason to do so differs forWanteds and Givens, but either way, deepest wins! Simple.* Wanteds. Putting the deepest variable on the left maximise the chances that it's a touchable meta-tyvar which can be solved.* Givens. Suppose we have something like forall a[2]. b[1] ~ a[2] => beta[1] ~ a[2] If we orient the Given a[2] on the left, we'll rewrite the Wanted to (beta[1] ~ b[1]), and that can float out of the implication. Otherwise it can't. By putting the deepest variable on the left we maximise our changes of eliminating skolem capture. See also TcSMonad Note [Let-bound skolems] for another reason to orient with the deepest skolem on the left. IMPORTANT NOTE: this test does a level-number comparison on skolems, so it's important that skolems have (accurate) level numbers.See #15009 for an further analysis of why "deepest on the left"is a good plan.``` I'm wondering about the claim "and that can float out of the implication". The Note does go on to mention #15009 --- and I understand how that Wanted floats *with* #15009 --- but as written, it sounds like the Wanted could float even without #15009. Am I missing something? Roughly: I'm asking because I need to decide if there's a reason for my typechecker plugin to bother with "eliminating skolem capture" when #15009 does *not* apply. Thanks. -Nick

2 1

Re: CI on forked projects: Darwin woes
by Carter Schonwald 15 May '19

15 May '19

Cool. I recommend irc and devs list plus urls / copies of error messages. Hard to debug timeout if we don’t have the literal url or error messages shared ! -Carter ________________________________ From: Kevin Buhr <buhr(a)asaurus.net> Sent: Sunday, May 12, 2019 11:01 AM To: Carter Schonwald Cc: Iavor Diatchki Subject: Re: CI on forked projects: Darwin woes Thanks! I'll send a note if it starts happening again. On 5/12/19 7:23 AM, Carter Schonwald wrote: > [ . . . ] > Next time you hit a failure could you share with the devs list and or > #ghc irc ? -- Kevin Buhr <buhr(a)asaurus.net>

2 2