- ghc-devs - Haskell.org

arcanist-external-json-linter missing commits
by Edward Z. Yang 10 Dec '15

10 Dec '15

On a git submodule update on HEAD, I get: fatal: reference is not a tree: 85ece0f8653e7b1e7de6024d372cfeaf36ab5fa9 Unable to checkout '85ece0f8653e7b1e7de6024d372cfeaf36ab5fa9' in submodule path '.arc-linters/arcanist-external-json-linter' Edward

2 2

Does the Strict extension make monadic bindings strict?
by Rob Stewart 10 Dec '15

10 Dec '15

Are the following two programs equivalent with respect to the strictness of `readFile`? --8<---------------cut here---------------start------------->8--- {-# LANGUAGE BangPatterns #-} module Main where main = do !contents <- readFile "foo.txt" print contents --8<---------------cut here---------------end--------------->8--- And: --8<---------------cut here---------------start------------->8--- {-# LANGAUGE Strict #-} module Main where main = do contents <- readFile "foo.txt" print contents --8<---------------cut here---------------end--------------->8--- The documentation on "Strict-by-default pattern bindings" gives let/where binding as an example, but there is not a monadic bind example. http://downloads.haskell.org/~ghc/master/users-guide/glasgow_exts.html#stri… Inspecting GHC Core for these two programs suggests that !contents <- readFile "foo.txt" is not equivalent to (with Strict enabled): contents <- readFile "foo.txt" Here's core using BangPatterns: (readFile (unpackCString# "foo.txt"#)) (\ (contents_asg :: String) -> case contents_asg of contents1_Xsk { __DEFAULT -> print @ String $dShow_rYy contents1_Xsk }) Here's core using Strict: (readFile (unpackCString# "foo.txt"#)) (\ (contents_asg :: String) -> print @ String $dShow_rYv contents_asg) Does this core align with the design of the Strict extension? If it does, are users going to understand that using Strict is going to make let/where bindings strict, but is not going to make <- or >>= bindings strict? -- Rob Stewart

5 5

Re: [Haskell-cafe] [ANNOUNCE] Glasgow Haskell Compiler version 7.10.3
by Ben Gamari 09 Dec '15

09 Dec '15

Ivan Lazar Miljenovic <ivan.miljenovic(a)gmail.com> writes: > On 9 December 2015 at 23:17, Ben Gamari <ben(a)well-typed.com> wrote: >> >> >> [1] http://downloads.haskell.org/~ghc/7.10.3/docs/html/users_guide//release-7-1… > > The links to Trac issues in that page seem to redirect to the same page. > Indeed, I'm trying to work out what went wrong here. I am quite looking forward to being able to drop DocBook in 8.0. Cheers, - Ben

1 0

RE: D808 progress report
by Simon Peyton Jones 09 Dec '15

09 Dec '15

Kind equalities are the Big New Thing in 8.0. Let's just get it in and deal with the fallout. After all, there is no reason for performance to be worse. For programs that 7.10 accepts, 8.0 should yield essentially the same coercions. They might need a bit of optimisation to squeeze them down but the result should be essentially identical. If not, let's investigate. I could imagine the typechecker being a bit slower, but not a lot. For T3738, compile the compiler before and after with -ticky and compare. | In light of all this, I propose the following: | - Scramble to fix all non-perf failures. I expect I can finish this by | Wed evening. | - Hope that one of you (or another dev) can take a look at T3738 and | friends. That clearly needs to get fixed. | - Adjust perf targets to get validation to work, clearly labeling the | remaining problems as the fault of type=kind. | - Commit to fixing #8095 in the next two weeks. But probably not by | early next week, I'm afraid. | In short, yes. Simon | -----Original Message----- | From: Richard Eisenberg [mailto:eir@cis.upenn.edu] | Sent: 08 December 2015 03:35 | To: Simon Peyton Jones <simonpj(a)microsoft.com>; Ben Gamari <ben@well- | typed.com>; Austin Seipp <aseipp(a)pobox.com> | Subject: D808 progress report | | Hi Simon, Ben, Austin, | | First, the bad news: | I'm a bit stalled on performance issues. When I sent my earlier email, | I was celebrating having gotten one test case from 319M of allocation | down to 182M via several seemingly general-purpose optimizations. But | this was with -fno-opt-coercion. Once I re-enabled coercion | optimization, that particular test case still fails | (pert/compiler/T5030), along with 22 others. This is bad. But many ~4 | hours of effort this evening I've made no substantive progress at all, | shaving off maybe 1% of allocation via a few tiny tweaks. Even | characterizing what's going wrong is proving difficult. I've only | analyzed a few of the failing tests, but each one is stubbornly | refusing to break, so I'm losing hope about the others. | | Then, the good news: | I think the idea posited in #8095 (not to bother building coercions | unless -dcore-lint is on) will solve all of these problems and more, | as long as users don't use -dcore-lint. With one exception that I've | noticed (see below), my performance failures aren't catastrophic: on | the performance tests, which tend to be pathological, my branch is | running 10-20% worse than HEAD. Not good, but not so bad that -dcore- | lint users can't cope. So, with #8095 addressed, I think we'll be OK. | And #8095 should be very straightforward and done in a few hours' | work. | | Finally, the ugly: | The exception to the non-catastrophic nature of the failures is this: | perf/should_run/T3738 fails with 3479.1% overage. (Yes, the percentage | is in the thousands.) Worse, this is at runtime, not in the compiler. | Yet the Core produced in my branch (as observed by -ddump-simpl) and | in HEAD appears identical. There are a few other should_run failures | that have me nervous, but my guess is that they're all from one | source. I'd love an offer of help to debug this. | | | In light of all this, I propose the following: | - Scramble to fix all non-perf failures. I expect I can finish this by | Wed evening. | - Hope that one of you (or another dev) can take a look at T3738 and | friends. That clearly needs to get fixed. | - Adjust perf targets to get validation to work, clearly labeling the | remaining problems as the fault of type=kind. | - Commit to fixing #8095 in the next two weeks. But probably not by | early next week, I'm afraid. | | What do we think? | | Thanks, | Richard

3 7

Re: runghc fails on Windows with GHC HEAD
by Ryan Scott 08 Dec '15

08 Dec '15

Actually, this might not be Windows-related at all. It turns out that runghc was failing because there wasn't a ghc.exe located in inplace/bin (just ghc-stage1.exe and ghc-stage2.exe). Adding a ghc.exe symlink to ghc-stage2.exe made runghc.exe work correctly. Is this a bug, or the intended behavior? Ryan S.

2 1

runghc fails on Windows with GHC HEAD
by Ryan Scott 08 Dec '15

08 Dec '15

For some reason, I can't get runghc to work with GHC HEAD. Compiling with ghc-stage2 and running ghc-stage2 --interactive both work okay, it's just runghc that doesn't want to cooperate for some reason: $ .\ghc\inplace\bin\runghc.exe Z.hs runghc.exe: C:\Users\ryanscot\Documents\Software\ghc\inplace\bin\ghc: rawSystem: does not exist (No such file or directory) Does anyone have an idea of what might be happening here? Ryan S.

1 0

Non-exported class constraints in errors
by David Feuer 08 Dec '15

08 Dec '15

The latest implementation of Data.Constraint.Forall uses type family Forall (p :: k -> Constraint) :: Constraint where Forall p = Forall_ p class p (Skolem p) => Forall_ (p :: k -> Constraint) instance p (Skolem p) => Forall_ (p :: k -> Constraint) The trouble is that errors relating to Forall are reported with Skolem verbiage, making them incomprehensible to users -- the Skolem type family is not exported. It would be nice if GHC could keep track of what led to the p (Skolem p) constraint, and report that. The sanest idea I've come up with thus far is a "buck stops here" pragma. When GHC attempts to solve a constraint so marked, it will hold onto that fact, and report any failures against that. So {-# TheBuckStopsHere Forall #-} would make GHC take note when trying to solve Forall p, and report that it failed to solve Forall p, rather than that it failed to solve constraints further down the line.

1 0

Another question about -XStrict: Why not implement it as a Core pass?
by Ömer Sinan Ağacan 08 Dec '15

08 Dec '15

So this is another question comes to mind. It seems to me like it would be a lot easier to implement, we could even implement it as a plugin, without changing anything in GHC. (I mean -XStrict, not -XStrictData) I'm wondering why it's currently implemented on Haskell syntax. Any ideas? Is it because of some typechecking related things?

1 0

Submodules on a branch
by Simon Peyton Jones 08 Dec '15

08 Dec '15

· I’m on a branch wip/T11067. · I do a ‘git merge origin/master’, resolve source code conflicts and commit · Then ‘git submodule update’ · I have not touched libraries/unix · Yet when I say “git submodule” in a different HEAD tree, I get a different commit for libraries/unix than in my branch Question (sticking plaster): how can I say “Just make my sub-modules match HEAD please”? Question (cause): how can I ensure that I do update my branch to the submodule of HEAD when doing ‘git merge’? Getting submodules out of sync is very tiresome. Thanks Simon

2 1

Plugins: Accessing unexported bindings
by Levent Erkok 08 Dec '15

08 Dec '15

Hello, The mg_binds field of the ModGuts seem to only contain the bindings that are exported from the module being compiled. I guess GHC must be running user-plugins after it drops the bindings that are not exported, which makes perfect sense for most use cases. However, I'm working on a plugin where the end-programmer embeds "properties" in the form of functions inside his/her code, which are not necessarily exported from the module under consideration. Is there a way to access all top-level bindings in a module from a plugin, even if those bindings are not exported? Thanks, -Levent.

6 17