- ghc-devs - Haskell.org

RE: Panic from rewritableTyVarsOfType
by Ben Gamari 03 Feb '17

03 Feb '17

Simon Peyton Jones <simonpj(a)microsoft.com> writes: > Ben, Richard > > rewritableTyVarsOfType is used when deciding whether to split a [WD] > constraint into [W] and [D]. For example, if we are adding > [WD] C a > and there is an inert > [WD] a ~ Int > then we want to split the [WD] into > [W] C a > [D] C a > so that the [D] one can be rewritten and perhaps yield improvement etc. > > There is no point in rewriting coercions or cases in t, because they > won't help (C t) to reduce. That's why rewriteableTyVarsOfType differs > from tyVarsOfType. And indeed the arg of a class C should be a > monotype. > Ahh, I see. > So rewriteableTyVarsOfType doesn't expect foralls, hence the panic. > But it's seeing a forall in an /equality/ constraint. > > FIRST ISSUE: I'm a bit surprised about that (smacks of impredicative > polymorphism) so the first thing to check is that this is really > supposed to happen in this program. Richard should be able to help. > Indeed this test is meant to fail, just not with a panic. I suspect this means that my solver logic isn't catching requests for polytypes as early as it needs to. > SECOND ISSUE: But regardless, I now realise that shouldSplitWD only > needs to split a [WD] equality if the LHS matches. If we have > [WD] a ~ ty -- work item > [D] a ~ ty2 -- inert > then we want to split the [WD] so we can get [D] ty ~ ty2. But > otherwise there is no point. > > Richard do you agree? > > I'll try that out. > > Meanwhile to get you rolling, you can replace rewritableTyVars with > tyCoVarsOfType and it'll all work, just a bit less efficiently. > Thanks Simon! Indeed that allows things to proceed and in the process, confirms that there is a bug in my solver logic. Cheers, - Ben

2 2

Disable messages with GHC API
by Christopher Done 03 Feb '17

03 Feb '17

In Intero, after loading modules, for each one I run the following function: https://github.com/commercialhaskell/intero/blob/300ac5a/src/GhciInfo.hs#L7… If there are warnings or any output, they get outputted. As they are already outputted by regular :load, I don’t need the same output twice. How do I disable non-severe output for any GhcMonad m => m a? I’m using GHC 8.0.1 presently. I tried the following before calling getModInfo, expecting there to be no output anymore: + GHC.setSessionDynFlags + df {log_action = \ref dflags severity srcSpan style msg -> return ()} And this had no effect. I tried some other things but ran out of patience to keep a record of them all. Ciao!

4 5

Talkative Join points warning
by Ben Gamari 03 Feb '17

03 Feb '17

Hi Luke, I've noticed that a new WARN in OccurAnal seems to be quite loud. Validations now produce thousands of lines of the form, WARNING: file compiler/simplCore/OccurAnal.hs, line 2633 OccurAnal failed to rediscover join point(s): [$j_shTG] WARNING: file compiler/simplCore/OccurAnal.hs, line 2633 OccurAnal failed to rediscover join point(s): [$w$j_sl22] WARNING: file compiler/simplCore/OccurAnal.hs, line 2633 OccurAnal failed to rediscover join point(s): [$w$j_sl1W] WARNING: file compiler/simplCore/OccurAnal.hs, line 2633 OccurAnal failed to rediscover join point(s): [$w$j_sl1Q] Do you think we could either quiet the warning down a bit or perhaps disable it by default? It makes it rather difficult to see through the noise. This is actually perhaps another case where Simon Marlow suggestion of introducing a family of -v* flags (e.g. -fvanishing-join-points) might be helpful. Cheers, - Ben

4 3

eagerlyBlackhole# efficiency thought
by David Feuer 02 Feb '17

02 Feb '17

We discussed trying to come up with a primitive eagerlyBlackhole# :: a -> a -- meaning eagerlyBlackhole a = runRW# $ \s -> case noDuplicate# s of _ -> a that would guarantee that the thunk is entered by only one thread. There are important situations where that check is redundant. Consider this code: (m >>= \a -> strictToLazyST (f a)) >>= o The implementation of >>= needs to wrap up the execution of its first argument in eagerlyBlackhole#. In this case, however, there is no risk that two threads will execute m, because it's forced within the same outer eagerlyBlackhole in which it was created. Is there a cheap way to detect this situation at run-time, when executing m, to avoid the synchronization delay? This probably doesn't arise too much for unsafePerformIO, but in lazy ST there may be a lot of nested no-duplicate thunks. I looked into trying to fix things up with RULES for *> and such, but I ran into trouble with eta expansion and in any case there are limits to what they can do to help >>=, and the whole thing is rather complicated.

1 0

Master broken?
by Simon Peyton Jones 02 Feb '17

02 Feb '17

My clean build of origin/master, on 64-bit Linux is showing these failures Unexpected failures: /tmp/ghctest-5_qx1p/test spaces/./pmcheck/should_compile/T11195.run T11195 [exit code non-0] (normal) Unexpected stat failures: /tmp/ghctest-5_qx1p/test spaces/./perf/compiler/T5837.run T5837 [stat too good] (normal) /tmp/ghctest-5_qx1p/test spaces/./perf/compiler/T12234.run T12234 [stat too good] (optasm) (I do wish the summary omitted those long paths; makes it hard to read.) I'm happy about the perf improvements, but why don't they happen for other people? T11195 is a very long-running pattern-match perf test that regularly fails on a heavily loaded machine, with a timeout. It's very tiresome, but I don't think it's a regression. Simon

2 1

RE: D2038: [WIP] TysPrim: Generalize kind of (->)
by Simon Peyton Jones 01 Feb '17

01 Feb '17

Replying by email because I'm on a train. Simon Huh. Put otherwise, your point is this. Suppose we have the following kind for `(->)`: (->) :: forall v1 v2 r1 r2. TYPE v1 r1 -> TYPE v2 r2 -> Type To coerce from (C a -> Int) to (a -> Int) we'd have to cough up a coercion `g`: g : (->) Vanilla Vanilla Ptr Ptr (C a) Int ~R (->) Constraint Vanilla Ptr Ptr a Int And now (Nth 1 g :: Vanilla ~R Constraint). Nothing about `KindCo` there; it's just that `(->)` takes some kind arguments. But that can only happen if `(->)` has suitable roles. What if it doesn't? What if we just had an axiom axArrow v :: (->) Vanilla v ~R (->) Constraint v or something like that. Then we get [W] g : (->) Vanilla Vanilla Ptr Ptr (C a) Int ~R (->) Constraint Vanilla Ptr Ptr a Int We decompose partly and solve thus g = (axArrow Vanilla) <Ptr> <Ptr> axC <Int> Simon From: noreply(a)phabricator.haskell.org [mailto:noreply@phabricator.haskell.org] Sent: 31 January 2017 12:51 To: Simon Peyton Jones <simonpj(a)microsoft.com> Subject: [Differential] [Commented On] D2038: [WIP] TysPrim: Generalize kind of (->) goldfire added a comment. View Revision<https://phabricator.haskell.org/D2038> In D2038#89360<https://phabricator.haskell.org/D2038#89360>, @simonpj<https://phabricator.haskell.org/p/simonpj/> wrote: To avoid being able to extract ContraintRep ~R LiftedPtrRep we decided to weaken one of the coercion constructors, the one that gets a kind coercion from a type coercion. We don't need it, and it's awkward here. The problem is that we need it with this patch. I was able to weaken this coercion constructor (KindCo) in my patch D3023<https://phabricator.haskell.org/D3023>, but this patch uses it in a fundamental way that we can't get around. To wit: class C a where meth :: a axC :: (C a :: Constraint) ~R (a :: Type) Now, we wish to cast C a -> a to a -> a.. This cast will look like (->) ?? <LiftedRep> axC <a>. What goes in the ??? It's got to be something involving KindCo axC, which is disallowed as per our earlier decision. Therein lies the problem. As for reify: Yes, I'm agreed with that email. But is that implemented yet? Is a design settled on? I don't see a ghc-proposal. Are we wiling to take a dependency on that work in order to get this done? To be clear, my chief worry isn't that these problems cannot be solved by any means -- I'm just worried about the timing of this all and our desire to get 8.2 out the door. REPOSITORY rGHC Glasgow Haskell Compiler REVISION DETAIL https://phabricator.haskell.org/D2038 EMAIL PREFERENCES https://phabricator.haskell.org/settings/panel/emailpreferences/ To: bgamari, goldfire, austin Cc: simonpj, RyanGlScott, thomie

3 8

More history in perf.haskell.org graphs
by Reid Barton 01 Feb '17

01 Feb '17

Hi Joachim, The graphs like https://perf.haskell.org/ghc/#graph/buildtime/make are very helpful, but I haven't found a way to adjust the range of commits shown from the default of the last 50 commits. For example, suppose I wanted to see the history of build time over the past 12 months and then narrow in on commits that caused regressions. Is there a way to do that using the https://perf.haskell.org/ghc/ website? Failing that, is the data that goes into these graphs available for download in some form? Regards, Reid Barton

3 2

Lazy ST vs concurrency
by David Feuer 01 Feb '17

01 Feb '17

I forgot to CC ghc-devs the first time, so here's another copy. I was working on #11760 this weekend, which has to do with concurrency breaking lazy ST. I came up with what I thought was a pretty decent solution ( https://phabricator.haskell.org/D3038 ). Simon Peyton Jones, however, is quite unhappy about the idea of sticking this weird unsafePerformIO-like code (noDup, which I originally implemented as (unsafePerformIO . evaluate), but which he finds ugly regardless of the details) into fmap and (>>=). He's also concerned that the noDuplicate# applications will kill performance in the multi-threaded case, and suggests he would rather leave lazy ST broken, or even remove it altogether, than use a fix that will make it slow sometimes, particularly since there haven't been a lot of reports of problems in the wild. My view is that leaving it broken, even if it only causes trouble occasionally, is simply not an option. If users can't rely on it to always give correct answers, then it's effectively useless. And for the sake of backwards compatibility, I think it's a lot better to keep it around, even if it runs slowly multithreaded, than to remove it altogether. Note to Simon PJ: Yes, it's ugly to stick that noDup in there. But lazy ST has always been a bit of deep magic. You can't *really* carry a moment of time around in your pocket and make its history happen only if necessary. We can make it work in GHC because its execution model is entirely based around graph reduction, so evaluation is capable of driving execution. Whereas lazy IO is extremely tricky because it causes effects observable in the real world, lazy ST is only *moderately* tricky, causing effects that we have to make sure don't lead to weird interactions between threads. I don't think it's terribly surprising that it needs to do a few more weird things to work properly. David

5 12

Join points revised
by Luke Maurer 01 Feb '17

01 Feb '17

Revised version of the join points patch is up: https://phabricator.haskell.org/D2853 Hoping to commit ASAP. Thanks all! - Luke Maurer University of Oregon maurerl(a)cs.uoregon.edu

3 2

Freeze update
by Ben Gamari 31 Jan '17

31 Jan '17

Hello everyone, As you likely know, the feature freeze date for the 8.2.1 was yesterday. Unfortunately, it looks like that date may have been a bit optimistic as there are there are still several major patches outstanding that we would like to have for 8.2.1. These are namely, * Join points rework (D2853) * Overloaded Record Fields (D2708) * Separation of the Constraint and Type types within GHC (D3023) * Generalization of the kind of (->) (D2038) * Type-indexed Typeable (D2010) * Use top-level instance to solve superclasses where possible (D2714) * A variety of DWARF patches While many of these patches are very close to completion, in sum they represent a significant amount of work. While I would love to be able to offer a concrete timeline for how we will proceed, at the moment I can only say that things are still rather up in the air. In particular, there are some thorny, late-rising design questions in D2038 and D3023 which are currently under discussion. If there are no obviously easy paths forward on these questions then we may be forced to retarget one or more of these patches to 8.4. I believe within the next few days we'll have a better idea of where we stand on these. Finally, note that unless you have spoken to me previously about merging your work for 8.2 we will not be considering any additional features at this point. Cheers, - Ben

1 0