January 2017 - ghc-devs

Default options for -threaded
by lonetiger＠gmail.com 04 Jan '19

04 Jan '19

Hi All, A user on https://ghc.haskell.org/trac/ghc/ticket/11054 has asked why -N -qa isn’t the default for -threaded. I’m afraid I don’t know a good reason why it’s not. Can anyone help shed some light on this? If there is no good reason, Would anyone object to making it the default? Thanks, Tamar

7 10

Cross-compiling Template Haskell via -fexternal-interpreter and IPC
by Alberto Valverde 30 May '17

30 May '17

Hello, I'm trying to put together a GHC 8.0.1 cross-compiler with Template Haskell support. Initially to target Windows (32bits) from a Linux host but a similar procedure should enable to target other platforms too. I'd like to contribute the patches back so I'm asking for advice on how to implement it in order to increase the chances of them being accepted. I've managed to get a working stage 1 cross-compiler with some patches which correctly builds all stage1 libs and GHC + stage 2 compiler and ghc-iserv.exe. However, compiling TH by using wine and ghc-iserver.exe fails because the file descriptor ids that GHC passes as arguments to "wine ghc-iserv.exe" don't make sense in the emulated windows world. I've hacked around this to test the feasibility of the approach by using stdin/stdout instead of creating new pipes and, surprisingly, managed to cross-compile a simple Template Haskell program. I'm considering using a socket for communicating between both processes as a more permanent solution but this would incur in a dependency on the "network" package. Would this be acceptable? Named pipes have also crossed my mind but I'm not sure how well they're supported by wine. Thanks for your attention. Alberto P.S: Code is in the "cross-mingw-hacks" branches of these repositories and is based on the ghc-8.0.1-release tag: https://github.com/albertov/ghc https://github.com/albertov/hsc2hs A Docker image script here that builds it is here: https://github.com/albertov/ghc-cross-compiler-windows-x86

6 11

GHC 8.0.1-rc4 source tarball availability
by Ben Gamari 14 May '17

14 May '17

tl;dr: If you would like to produce a binary distribution for GHC 8.0.1-rc4 then let us know, grab the source distribution and start building. The binary distributions will be all released one week from today. Hello GHC packagers, I am happy to announce the release of the 8.0.1-rc4 source distribution to binary packagers. This release should resolve all of the issues noted in the release candidate 3 announcement. You will find the usual artifacts at http://downloads.haskell.org/~ghc/8.0.1-rc4/ For this candidate we are again following our new release policy [1], with a one-week delay between the release of the source and binary distributions. The goal of this policy is to give all platforms the opportunity for support from the first day of a release. If all of the expected binary releases are submitted before the week-long delay has elapsed, we will move forward with the release of the binaries on an accelerated schedule. It would be appreciated if you could reply to this message confirming that you intend to offer a binary distribution this release. Otherwise, let either Austin or I know if you have any trouble building your distribution. I have yet to push the ghc-8.0.1-rc4 tag in case we encounter unexpected issues but all of my builds with this tarball thusfar have gone quite well. Good luck and thanks for all of your work! Cheers, - Ben [1] https://mail.haskell.org/pipermail/ghc-devs/2016-March/011546.html

12 75

Improving trac notifications
by Matthew Pickering 12 Feb '17

12 Feb '17

I subscribe to the ghc-tickets[1] mailing list which provides updates to all trac tickets. This is very useful, however when a ticket description is updated the whole description is included in the email which makes it hard to see what actually changed. The web interface shows a nice diff[2] of the changes, I think it would be good if emails could also include a diff rather than the current quite useless output. After a bit of investigation, it appears that the easiest way to achieve this is apply a simple patch to our copy of trac. The current format is hard coded on line 558 in this module, it seems easy to modify this section to instead provide a diff. http://www.edgewall.org/docs/trac-trunk/epydoc/trac.ticket.notification-pys… There is also already a module which has the diff operations implemented which could be used. http://www.edgewall.org/docs/trac-trunk/epydoc/trac.versioncontrol.diff-mod… Another option would be to use something like the `AnnouncerPlugin`[3] but that seems like much more work and would still require someone to write a custom formatter. Any thoughts? Matt [1]: https://mail.haskell.org/mailman/listinfo/ghc-tickets [2]: https://ghc.haskell.org/trac/ghc/ticket/10873?action=diff&version=6 [3]: https://trac-hacks.org/wiki/AnnouncerPlugin

3 8

Phabricator upgrade tomorrow
by Ben Gamari 05 Feb '17

05 Feb '17

Hello everyone! Currently our Phabricator installation is quite old, based on a commit from last July. Given that I have a bit of breathing room now between 8.0.2 and 8.2.1, I'd like to take this opportunity to do an upgrade tomorrow if no one objects. Given that this is the first time I have attempted an upgrade, I expect this may take a few hours in the middle of the day EST. I would expect that the GHC Phabricator instance would be down for much of this time. Let me know if this will cause you undue burden. Cheers, - Ben

2 2

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

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

Re: Lazy ST vs concurrency
by David Feuer 31 Jan '17

31 Jan '17

I think Ben's eagerlyBlackhole is what I called noDup. And it is indeed a bit tricky to use correctly. It needs the same sort of care around inlining that unsafePerformIO does. A bit of summary: 1. It's okay to duplicate a runST thunk or to enter it twice, because each copy will have its own set of references and arrays. This is important, because we have absolutely no control over what the user will do with such a thunk. 2. With the exception of a runST thunk, we must never duplicate or double-enter a thunk if it performs or suspends ST work. Based on my tests and the intuition I've developed about what's going on here, (2) breaks down into two pieces: 2a. Any time we perform or suspend ST work, we must use NOINLINE to avoid duplication. 2b. Any time we suspend ST work, we must set up the thunk involved with noDuplicate# or similar. For example, the code I wrote yesterday for the Applicative instance looks like this: fm <*> xm = ST $ \ s -> let {-# NOINLINE res1 #-} !res1 = unST fm s !(f, s') = res1 {-# NOINLINE res2 #-} res2 = noDup (unST xm s') (x, s'') = res2 in (f x, s'') I NOINLINE res1. If it were to inline (could that happen?), we'd get let res2 = noDup (unST xm (snd (unST fm s))) (x, s'') = res2 in (fst (unST fm s) x, s') and that would run the fm computation twice. But I don't noDup res1, because we force it immediately on creation; no one else ever handles it. I NOINLINE res2 for a similar reason, but I also use noDup on it. The res2 thunk escapes into the wild via x and s'' in the result; we need to make sure that it is not entered twice. I believe can use a few rewrite rules to reduce costs substantially in some situations. I will add those to the differential. -------- Original message -------- From: Simon Marlow <marlowsd(a)gmail.com> Date: 1/31/17 3:59 AM (GMT-05:00) To: Simon Peyton Jones <simonpj(a)microsoft.com> Cc: David Feuer <david(a)well-typed.com>, ghc-devs(a)haskell.org Subject: Re: Lazy ST vs concurrency On 30 January 2017 at 22:56, Simon Peyton Jones <simonpj(a)microsoft.com[1]> wrote: We don’t want to do this on a per-module basis do we, as -fatomic-eager-blackholing would suggest. Rather, on per-thunk basis, no? Which thunks, precisely? I think perhaps *precisely thunks one of whose free variables has type (Sttate# s) for some s.* These are thunks that consume a state token, and must do so no more than once.

1 0