- ghc-devs - Haskell.org

Hoopl question
by Michal Terepeta 05 May '15

05 May '15

Hi, I've just read through the Hoopl paper and then noticed https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/HooplPerformance which is really interesting. But it seems that there were no updates to the page in like 3 years, yet the new codegen seems to be using Hoopl... Does anyone know what is the current status of this? Thanks, Michal

4 7

Help with GHC 7.10 on Homebrew?
by Mike Craig 04 May '15

04 May '15

Hey all, I'm trying to help improve the GHC-via-Homebrew situation. It's been busted for a while now. Someone opened a reasonable-looking PR to update the ghc formula. It removes a few bad hacks added over the years: https://github.com/Homebrew/homebrew/pull/39134 However, the build fails on CI when setting up HPC: > cat utils/hpc/hpc.wrapper >> inplace/bin/hpc > cat: utils/hpc/hpc.wrapper: No such file or directory The full log is here, with that error near the bottom: http://bot.brew.sh/job/Homebrew%20Pull%20Requests/25284/version=yosemite/te… Is this problem familiar to anyone? That formula builds on my laptop (also Yosemite), and I'm not familiar enough with the GHC build to know what to try next. Any help is much-appreciated! Mike

1 0

RE: Generalized Newtype Deriving not allowed in Safe Haskell
by Simon Peyton Jones 30 Apr '15

30 Apr '15

There is a long discussion on https://ghc.haskell.org/trac/ghc/ticket/8827 about whether the new Coercible story makes GND ok for Safe Haskell. At a type-soundness level, definitely yes. But there are other less-clear-cut issues like “breaking abstractions” to consider. The decision on the ticket (comment:36) seems to be: GND stays out of Safe Haskell for now, but there is room for a better proposal. I don’t have an opinion myself. David Terei and David Mazieres are in the driving seat, but I’m sure they’ll be responsive to user input. However, I think the user manual may not have kept up with #8827. The sentence “GeneralizedNewtypeDeriving — It can be used to violate constructor access control, by allowing untrusted code to manipulate protected data types in ways the data type author did not intend, breaking invariants they have established.” vanished from the 7.8 user manual (links below). Maybe it should be restored. Safe Haskell aficionados, would you like to offer a patch for the manual? And maybe also a less drastic remedy than omitting GND altogether? Simon From: Omari Norman [mailto:omari@smileystation.com] Sent: 09 April 2015 02:44 To: haskell Cafe Subject: Generalized Newtype Deriving not allowed in Safe Haskell When compiling code with Generalized Newtype Deriving and the -fwarn-unsafe flag, I get -XGeneralizedNewtypeDeriving is not allowed in Safe Haskell This happens both in GHC 7.8 and GHC 7.10. I thought I remembered reading somewhere that GNTD is now part of the safe language? The GHC manual used to state that GNTD is not allowed in Safe Haskell: https://downloads.haskell.org/~ghc/7.6.3/docs/html/users_guide/safe-haskell… But this language on GNTD not being part of the safe language was removed in the 7.8 manual: https://downloads.haskell.org/~ghc/7.8.2/docs/html/users_guide/safe-haskell… The GHC release notes don't say anything about this one way or the other. Thoughts?

3 9

Roles, GND, Data.Coerce
by David Terei 30 Apr '15

30 Apr '15

All, An issue that came up with GHC 7.8 was the design of Roles and Data.Coerce, with it's ability to break module abstractions by default, requiring programmers adopt explicit role annotations to enforce some types of invariants for abstract data types. Because of this issue, as of now, GND & Data.Coerce are still disabled in Safe Haskell. We'd like to change this but need feedback from everyone. I've written up a wiki page with lots of information on the issue: https://ghc.haskell.org/trac/ghc/wiki/SafeRoles Please read, it has information on how Roles work, the problem it raises and subtleties in the current system. Possible paths forward are also there, but I'll include below. Please be aware that this discussion is about Roles in general, not specifically how when using -XSafe. Ideally we'd come up with a solution that works regardless of if using Safe Haskell or not. I personally like option (3), although it isn't clear to me how hairy the implementation would be. == Possible Paths Forward for Roles == 1) Do Nothing -- Keep Roles & GND unchanged, keep them unsafe in Safe Haskell. 2) Accept as Safe -- Keep Roles & GND unchanged, accept them as safe in Safe Haskell and warn users that they neednominal role annotations on ADTs. 3) In-scope constructor restriction for lifting instances -- The newtype constructor restriction for unwrapping instances could be extended to both data types, and the lifting instances of Data.Coerce. This is, GND & Coercing under a type constructor is allowed if (a) all involved constructors are in scope, or (b) the constructors involved have been explicitly declared to allow coercion without them being in scope. I.e., (b) allows library authors to opt-into the current GHC behavior. This would require new syntax, probably just an explicit deriving Coercible statement. 4) Change default role to nominal -- This will prioritize safety over GND, and the belief is that it may break a lot of code. Worse, that it will be an ongoing tax as role annotations will be needed to enable GND. 5) Nominal default when constructors aren't exported -- When a module doesn't export all the constructors of a data type, then the type parameters of the data type should default to nominal. This heuristic seems to capture somewhat the intention of the user, but given the practice of defining an Internal module that exports everything, it seems of limited use. 6) Nominal default in future -- Add a new extension, SafeNewtypeDeriving that switches the default role to nominal, but continue to provide a deprecated GND extension to help with the transition. The claims in support of representational roles as default though believe that nominal by default has an ongoing, continuous tax, not just a transition cost. So it isn't clear that any scheme like this satisfies that argument. 7) Safe Haskell Specific -- Many of the above approaches could be adopted in a Safe Haskell specific manner. This isn't ideal as it makes safe-inference harder and Safe Haskell less likely to remain viable going forward. Richard suggests one such idea. == The belief by many people seems to be that (4) and (6) would be too much of burden. I'd like to avoid (7) if possible. It isn't clear to me if (7) ends up better than (2). I'm going to try to setup some infastructure for compiling Hackage so that we can measure how impactful these changes would be. Cheers, David

1 0

RE: [Diffusion] [Commented On] rGHCb61562feb876: Seed SpecConstr from local calls
by Simon Peyton Jones 30 Apr '15

30 Apr '15

Thanks! I've added a comment to the relevant Note to document the effect. Simon | -----Original Message----- | From: noreply(a)phabricator.haskell.org | [mailto:noreply@phabricator.haskell.org] | Sent: 30 April 2015 08:10 | To: Simon Peyton Jones | Subject: [Diffusion] [Commented On] rGHCb61562feb876: Seed SpecConstr | from local calls | | nomeata added a subscriber: nomeata. | nomeata added a comment. | | Nice: -4% alloc in nofib/multiplier, -2.8% in nofib/minimax. 👍 | | | USERS | simonpj (Author) | GHC - Core/System FC (Auditor) | | COMMIT | https://phabricator.haskell.org/rGHCb61562feb876 | | EMAIL PREFERENCES | https://phabricator.haskell.org/settings/panel/emailpreferences/ | | To: simonpj, GHC - Core/System FC | Cc: nomeata

1 0

Fixing anchors in GHC docs
by Eric Crockett 28 Apr '15

28 Apr '15

I think I sent this out already, but never heard back. An issue was fixed in HsColour regarding HTML anchors in the GHC docs, documented here: https://github.com/haskell/hackage-server/issues/319 Apparently GHC devs upload their own documentation [to hackage], which means HsColour needs to be updated on your end so that anchors are correct the next time docs are generated. -Eric

1 0

Re: API Annotations and 7.10.2
by Alan & Kim Zimmerman 28 Apr '15

28 Apr '15

As you can see in the report below, there are a LOT of patches related to API Annotations. I am beginning to have difficulty keeping them up to date, as master moves ahead. I would like to request that as many of these as possible be merged into master sooner rather than later, subject to review approval. There can then be a secondary process to evaluate which of them actually belong in 7.10.2. If it would simplify things, I can collapse some of these into a mega patch. Regards Alan Report follows .... --------------------------------------------------------------- This is the current state of the patches proposed for 7.10.2 Landed in ghc-7.10 (thank you) #10207 D803 #10214 D806 Landed in master but not ghc-7.10 (also thank you) #10209 D813 #10256 D818 #10254 D822 #10255 D823 #10277 D829 Patches available #10269 D832 #10299 D840 * #10268 D825 * #10278 D833 * #10307 D842 * #10309 D848 * #10280 D834 #10287 D837 #10312 D846 #10354/#10315 D868 #10357 D869 #10358 D873 The ones marked with * form a dependent chain of merges Moved from 7.10.2 to 7.12 #10250 D815 The proposed patches all make minor changes to the Parser / RdrHsSyn, and do not affect the AST or Haddock, nor change the operation of the compiler. The one with the largest impact is D840, which corrects a conflict in the parser and now generates the correct type for '[] (`HsExplicitListTy` rather than `HsTyVar'). The merge process to produce https://github.com/alanz/ghc/tree/api-annotations is --------------------------- (2015-04-26) git checkout api-annotations git reset --hard master arc patch --nobranch D832 (cd libraries/Cabal && git checkout bda1ce6b757cdaca93f2eba4e1906a4658719537) to revert to the master libraries/Cabal submodule change) arc patch --nobranch D840 arc patch --nobranch D825 (manual fixup) arc patch --nobranch D833 (manual fixup) arc patch --nobranch D842 (manual fixup) arc patch --nobranch D848 (manual fixup) arc patch --nobranch D834 (manual fixup) arc patch --nobranch D837 (manual fixup) arc patch --nobranch D846 (manual fixup) arc patch --nobranch D868 (manual fixup) arc patch --nobranch D869 arc patch --nobranch D873 (manual fixup) On Fri, Apr 17, 2015 at 7:22 PM, Alan & Kim Zimmerman <alan.zimm(a)gmail.com> wrote: > This is the current state of the patches proposed for 7.10.2 > > Landed in ghc-7.10 (thank you) > #10207 D803 > #10214 D806 > > Landed in master but not ghc-7.10 (also thank you) > #10209 D813 > #10256 D818 > #10254 D822 > #10255 D823 > #10277 D829 > > Patches available > #10269 D832 > #10299 D840 * > #10268 D825 * > #10278 D833 * > #10307 D842 * > #10309 D848 * > #10280 D834 > #10287 D837 > #10312 D846 > > The ones marked with * form a dependent chain of merges > > Patches still to be finalised/provided > #10314 > #10315 > > Moved from 7.10.2 to 7.12 > #10250 D815 > > The proposed patches all make minor changes to the Parser / RdrHsSyn, and > do not affect the AST or Haddock, nor change the operation of the compiler. > > The one with the largest impact is D840, which corrects a conflict in the > parser and now generates the correct type for '[] (`HsExplicitListTy` > rather than `HsTyVar'). > > > The merge process to produce > https://github.com/alanz/ghc/tree/api-annotations is > > --------------------------- (2015-04-17) > git checkout -b api-annotations > arc patch --nobranch D832 > arc patch --nobranch D840 > arc patch --nobranch D825 (manual fixup) > arc patch --nobranch D833 > arc patch --nobranch D842 > arc patch --nobranch D848 (manual fixup) > arc patch --nobranch D834 (manual fixup) > arc patch --nobranch D837 (manual fixup) > arc patch --nobranch D846 (manual fixup) > -------------------------------------------------- > > I am really keen to get these landed, as being able to round-trip haskell > source using the annotations is the foundation of Matt Pickerings GSOC > proposal, and it would be a pity if it could not achieve its full potential. > > Regards > Alan > > > On Mon, Apr 13, 2015 at 12:14 AM, Alan & Kim Zimmerman < > alan.zimm(a)gmail.com> wrote: > >> This is the state of the nation for API Annotations for 7.10.2 >> >> The following are ready for merging, in the order proposed. The first >> four depend on each other. >> >> #10209 D813 >> #10256 D818 (depends D813) >> #10254 D822 (depends D818) >> #10269 D832 (depends D822) >> >> #10255 D823 >> >> #10268 D825 >> #10278 D833 (depends D825) >> >> #10280 D834 >> >> #10277 D829 >> >> #10287 D837 >> >> >> These are the commands I used to apply them to a freshly checked out ghc >> tree. The manual fixup is for Makefile, .gitignore, all.T, basically keep >> both legs each time. >> >> -------------------------- >> git checkout -b api-annotations >> arc patch --nobranch D832 >> arc patch --nobranch D823 (manual fixup) >> arc patch --nobranch D825 (manual fixup) >> arc patch --nobranch D834 (manual fixup) >> arc patch --nobranch D829 >> arc patch --nobranch D837 (manual fixup) >> arc patch --nobranch D833 (manual fixup) >> -------------------------- >> >> Once these are in, I do not think there will be anything else. >> >> Regards >> Alan >> >> >> >

1 0

Can we fix our Trac that doesn't lose new ticket text
by Edward Z. Yang 24 Apr '15

24 Apr '15

Steps to reproduce: 1. Click "New Ticket" 2. Type some text into the box 3. Press "Back" in your browser 4. Press "Forward" in your browser If you try this with an official Trac this doesn't happen, so either this was fixed in a new version, or we have a plugin installed which is causing this to happen. Current version of Trac is 1.0.5, we're currently running 1.0.1 Thanks, Edward

7 9

validate failures for OSX on current head
by Carter Schonwald 23 Apr '15

23 Apr '15

hey all, on ghc head today specifically commit a55bfabbed21f17064f863450f9d94d45db9c478 i did a run of ./validate --slow here are the following unexpected failures (i know the static pointer GHCI ones are expected, but i'm not sure about the rest). Could someone care to opine on which ones are truely unexpected? i'll be doing a bit of digging on some of these as I have time over the coming week, but i thought I should share this with everyone just in case something important is amidst them cheers -Carter Unexpected results from: TEST="tc165 retc001 dsrun014 DsStaticPointers GcStaticPointers ListStaticPointers T7919 retc002 tcrun024 tcrun025 T7861 T5751 T3500a T7126 tcrun037 readRun004 rn041 TH_StaticPointers recomp001 setnumcapabilities001 allocLimit4 ghci024 termination enum01 enum03 enum02 sigcabal01 sigcabal02 CgStaticPointers recomp014 qq007 qq008 mul2 quotRem2 add2 read029" OVERALL SUMMARY for test run started at Thu Apr 23 15:02:33 2015 EDT 0:20:10 spent to go through 4483 total tests, which gave rise to 14464 test cases, of which 2785 were skipped 267 had missing libraries 11140 expected passes 170 expected failures 0 caused framework failures 0 unexpected passes 102 unexpected failures 0 unexpected stat failures Unexpected failures: ../../libraries/base/tests enum01 [exit code non-0] (normal,hpc,optasm,threaded1,threaded2,dyn) ../../libraries/base/tests enum01 [bad stdout or stderr] (ghci) ../../libraries/base/tests enum02 [exit code non-0] (normal,hpc,optasm,threaded1,threaded2,dyn) ../../libraries/base/tests enum02 [bad stdout or stderr] (ghci) ../../libraries/base/tests enum03 [exit code non-0] (normal,hpc,optasm,threaded1,threaded2,dyn) ../../libraries/base/tests enum03 [bad stdout or stderr] (ghci) cabal/sigcabal01 sigcabal01 [bad stderr] (normal) cabal/sigcabal02 sigcabal02 [bad stderr] (normal) codeGen/should_run CgStaticPointers [bad stdout or stderr] (ghci) concurrent/should_run allocLimit4 [bad exit code] (ghci) concurrent/should_run setnumcapabilities001 [bad exit code] (threaded2) deSugar/should_run DsStaticPointers [bad stdout or stderr] (ghci) deSugar/should_run dsrun014 [bad exit code] (ghci) driver/recomp001 recomp001 [bad stderr] (normal) driver/recomp014 recomp014 [bad stdout] (normal) driver/retc001 retc001 [bad exit code] (normal) driver/retc002 retc002 [bad exit code] (normal) gadt termination [exit code non-0] (optasm) ghci/scripts ghci024 [bad stdout] (normal) numeric/should_run add2 [bad exit code] (ghci) numeric/should_run mul2 [bad exit code] (ghci) numeric/should_run quotRem2 [bad exit code] (ghci) parser/should_compile read029 [exit code non-0] (optasm) parser/should_run readRun004 [bad exit code] (ghci) quasiquotation/qq007 qq007 [exit code non-0] (normal,hpc,optasm) quasiquotation/qq008 qq008 [exit code non-0] (normal,hpc,optasm) rename/should_compile rn041 [exit code non-0] (optasm) rts GcStaticPointers [bad stdout or stderr] (ghci) rts ListStaticPointers [bad stdout or stderr] (ghci) rts T7919 [bad exit code] (optasm,threaded1,dyn) th TH_StaticPointers [bad stdout or stderr] (ghci) typecheck/should_compile tc165 [exit code non-0] (optasm) typecheck/should_run T3500a [exit code non-0] (normal,hpc,optasm,threaded1,threaded2,dyn) typecheck/should_run T3500a [bad stdout or stderr] (ghci) typecheck/should_run T5751 [exit code non-0] (normal,hpc,optasm,threaded1,threaded2,dyn) typecheck/should_run T5751 [bad stdout or stderr] (ghci) typecheck/should_run T7126 [exit code non-0] (normal,hpc,optasm,threaded1,threaded2,dyn) typecheck/should_run T7126 [bad stdout or stderr] (ghci) typecheck/should_run T7861 [bad stderr] (normal,hpc,optasm,threaded1,threaded2,dyn) typecheck/should_run T7861 [bad stdout or stderr] (ghci) typecheck/should_run tcrun024 [exit code non-0] (normal,hpc,optasm,threaded1,threaded2,dyn) typecheck/should_run tcrun024 [bad stdout or stderr] (ghci) typecheck/should_run tcrun025 [exit code non-0] (normal,hpc,optasm,threaded1,threaded2,dyn) typecheck/should_run tcrun025 [bad stdout or stderr] (ghci) typecheck/should_run tcrun037 [exit code non-0] (normal,hpc,optasm,threaded1,threaded2,dyn) typecheck/should_run tcrun037 [bad stdout or stderr] (ghci)

1 0

deriving Typeable and Nat kinds
by Gabor Greif 23 Apr '15

23 Apr '15

Hi devs, between ghc-7.11.20150215 and ghc-7.11.20150407 I experienced a strange regression with deriving Typeable for data with Nat-kinded indices. Something like this used to work (I cannot post the whole thing, unfortunately) {{{ data OTU (p :: Nat) (o :: Nat) = OTU { ...fields... } deriving (Show, Typeable) }}} With my ghc-7.11.20150407 (and later) strange obligations of the form `Typeable p` appear, rendering my code uncompilable. But there is no way I can see how I can convince the type checker that the Nat index is indeed Typeable. I *do* have a `KnownNat p` constraint around, though. The relevant changes to mainline appear to be https://github.com/ghc/ghc/commit/b359c886cd7578ed083bcedcea05d315ecaeeb54 https://github.com/ghc/ghc/commit/3a0019e3672097761e7ce09c811018f774febfd2 both by Iavor. So now my questions: 1) Is this a regression on mainline? (I surely hope so!) How did this work before? 2) Should `KnownNat p` imply `Typeable p` for the ability to have my `Typeable (OTU p o)` 3) if 2) is answered with "NO", how am I supposed to satisfy those constraints? Thanks and cheers, Gabor PS: Sometimes I feel like a canary doing my research-like programming with GHC-HEAD, and it is a mostly positive experience, but events like this make me shiver...

2 5