- ghc-devs - Haskell.org

Unprincipled defaults
by David Feuer 02 Sep '16

02 Sep '16

On occasion, it can be useful to have default definitions that don't typecheck even with DefaultSignatures. It would be nice to be able to use them anyway. For example, if we have class Semigroup1 f where op :: f a -> f a -> f a then we could, hypothetically, give a default definition for (<>): default (<>) :: Semigroup1 f => f a -> f a -> f a (<>) = op But we can't give a default definition op = (<>) because there's no way to write its signature. However, for any F with instance Semigroup (F a) where ... the definition op = (<>) is perfectly fine. Would it be possible to offer a completely wild defaulting mechanism allowing *any expression* as a default, and only checking its type and compiling it when it's actually used?

2 2

Build GHC on Windows using Hadrian and Stack
by Andrey Mokhov 02 Sep '16

02 Sep '16

Hi all, Summary: Building GHC on Windows using Hadrian and Stack got even simpler - see https://github.com/snowleopard/hadrian/blob/master/doc/windows.md. To build GHC on Windows you usually need to jump through a lot of hoops [1], which may be confusing even for experienced GHC developers [2]. Hadrian to the rescue! Hadrian, a new build system for GHC that I've been developing [3], is written in Haskell and can therefore be built and run via Stack that can install appropriate bootstrapping GHC and MSYS2 environment in an automated and robust way. This was first pointed out by Neil Mitchell [4], and I've recently simplified build instructions even further. Here are all the steps: git clone --recursive git://git.haskell.org/ghc.git cd ghc git clone git://github.com/snowleopard/hadrian cd hadrian stack setup stack exec -- pacman -S autoconf automake-wrapper make patch tar --noconfirm stack build stack exec hadrian -- --directory ".." -j --flavour=quickest See more details here: https://github.com/snowleopard/hadrian/blob/master/doc/windows.md. NB: Hadrian can build Stage2 GHC, but there are still many limitations [5]. Help make it better! [1] https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows [2] https://mail.haskell.org/pipermail/ghc-devs/2016-June/012340.html [3] https://github.com/snowleopard/hadrian [4] http://neilmitchell.blogspot.co.uk/2016/03/compiling-ghc-on-windows.html [5] https://github.com/snowleopard/hadrian#current-limitations Cheers, Andrey

2 1

Phabricator diffs not viewable by non-logged in users
by Edward Z. Yang 01 Sep '16

01 Sep '16

For example, if I am not logged in (try an incognito/private browsing session), https://phabricator.haskell.org/D2501 reports an error. Is this intentional? Seems poor, and also the diff is labeled as Public in the UI. I found this quite surprising. Edward

3 2

Last call for merge requests for 8.0.2
by Ben Gamari 01 Sep '16

01 Sep '16

tl;dr. GHC 8.0.2 is coming. If you have a fix which you'd like to see merged into 8.0.2 and isn't already present in the tree, please speak up! Hello everyone, Over the last week I have been working down the (rather long) merge queue for the ghc-8.0 branch in preparation for a 8.0.2 release. At this point I think have merged nearly everything which will likely make it in to 8.0.2. If you have a patch which hasn't made it to the ghc-8.0 branch that you would like to see merged, please raise your concern on the appropriate Trac ticket. Thanks! - Ben

5 7

hsc2hs fix
by Richard Cook 31 Aug '16

31 Aug '16

Ben et al, I'm responding to your last call for merge requests ( https://mail.haskell.org/pipermail/ghc-devs/2016-August/012693.html) I would really like to get this fix to hsc2hs in if it all possible: https://phabricator.haskell.org/D2478 Thanks, Richard.

2 1

RE: [commit: ghc] master: Remove unused DerivInst constructor for DerivStuff (f4384ef)
by Simon Peyton Jones 30 Aug '16

30 Aug '16

Ryan I just wanted to thank you for all the work you are doing on 'deriving' and generics. It's a very useful part of GHC, but it's sufficiently complicated that it's hard to dive in and make a quick fix. You are giving it sustained attention, and have become very familiar with the code, which is exactly what it needs. Thank you! It's extremely valuable work. I am conscious that I owe you a code review on D2280, but this week is bad and next week is worse. If I don't get to it, let's sit down at ICFP. I should not be standing in the way. Has anyone else given it a good review? Simon -----Original Message----- From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf Of git(a)git.haskell.org Sent: 29 August 2016 20:29 To: ghc-commits(a)haskell.org Subject: [commit: ghc] master: Remove unused DerivInst constructor for DerivStuff (f4384ef) Repository : ssh://git@git.haskell.org/ghc On branch : master Link : https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fghc.haskell… >--------------------------------------------------------------- commit f4384ef5b42bb64b55d6c930ed9850a021796f36 Author: Ryan Scott <ryan.gl.scott(a)gmail.com> Date: Mon Aug 29 15:26:53 2016 -0400 Remove unused DerivInst constructor for DerivStuff Summary: Back when derived `Generic` instances used to generate auxiliary datatypes, they would also generate instances for those datatypes. Nowadays, GHC generics uses a `DataKinds`-based encoding that requires neither auxiliary datatypes (corresponding to the `DerivTyCon` constructor of `DerivStuff`) nor instances for them (the `DerivInst` constructor of `DerivStuff`). It appears that `DerivTyCon` constructor was removed at some point, but `DerivInst` never was. No `DerivInst` values are ever constructed, so we can safely remove it. Test Plan: It builds Reviewers: austin, hvr, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2481 >--------------------------------------------------------------- f4384ef5b42bb64b55d6c930ed9850a021796f36 compiler/typecheck/TcDeriv.hs | 5 ++--- compiler/typecheck/TcGenDeriv.hs | 22 +++++++++------------- 2 files changed, 11 insertions(+), 16 deletions(-) diff --git a/compiler/typecheck/TcDeriv.hs b/compiler/typecheck/TcDeriv.hs index 70eaf5c..e38cfdc 100644 --- a/compiler/typecheck/TcDeriv.hs +++ b/compiler/typecheck/TcDeriv.hs @@ -387,13 +387,12 @@ tcDeriving deriv_infos deriv_decls ; let (inst_infos, deriv_stuff, maybe_fvs) = unzip3 (insts1 ++ insts2) ; loc <- getSrcSpanM - ; let (binds, famInsts, extraInstances) = - genAuxBinds loc (unionManyBags deriv_stuff) + ; let (binds, famInsts) = genAuxBinds loc (unionManyBags + deriv_stuff) ; dflags <- getDynFlags ; (inst_info, rn_binds, rn_dus) <- - renameDeriv is_boot (inst_infos ++ (bagToList extraInstances)) binds + renameDeriv is_boot inst_infos binds ; unless (isEmptyBag inst_info) $ liftIO (dumpIfSet_dyn dflags Opt_D_dump_deriv "Derived instances" diff --git a/compiler/typecheck/TcGenDeriv.hs b/compiler/typecheck/TcGenDeriv.hs index 2eb8c07..dce0b16 100644 --- a/compiler/typecheck/TcGenDeriv.hs +++ b/compiler/typecheck/TcGenDeriv.hs @@ -70,7 +70,6 @@ import Lexeme import FastString import Pair import Bag -import TcEnv (InstInfo) import StaticFlags( opt_PprStyle_Debug ) import ListSetOps ( assocMaybe ) @@ -90,12 +89,11 @@ data AuxBindSpec data DerivStuff -- Please add this auxiliary stuff = DerivAuxBind AuxBindSpec - -- Generics + -- Generics and DeriveAnyClass | DerivFamInst FamInst -- New type family instances -- New top-level auxiliary bindings | DerivHsBind (LHsBind RdrName, LSig RdrName) -- Also used for SYB - | DerivInst (InstInfo RdrName) -- New, auxiliary instances {- ************************************************************************ @@ -2346,11 +2344,11 @@ genAuxBindSpec loc (DerivMaxTag tycon) max_tag = case (tyConDataCons tycon) of data_cons -> toInteger ((length data_cons) - fIRST_TAG) -type SeparateBagsDerivStuff = -- AuxBinds and SYB bindings - ( Bag (LHsBind RdrName, LSig RdrName) - -- Extra bindings (used by Generic only) - , Bag (FamInst) -- Extra family instances - , Bag (InstInfo RdrName)) -- Extra instances +type SeparateBagsDerivStuff = + -- AuxBinds and SYB bindings + ( Bag (LHsBind RdrName, LSig RdrName) + -- Extra family instances (used by Generic and DeriveAnyClass) + , Bag (FamInst) ) genAuxBinds :: SrcSpan -> BagDerivStuff -> SeparateBagsDerivStuff genAuxBinds loc b = genAuxBinds' b2 where @@ -2363,16 +2361,14 @@ genAuxBinds loc b = genAuxBinds' b2 where genAuxBinds' :: BagDerivStuff -> SeparateBagsDerivStuff genAuxBinds' = foldrBag f ( mapBag (genAuxBindSpec loc) (rm_dups b1) - , emptyBag, emptyBag) + , emptyBag ) f :: DerivStuff -> SeparateBagsDerivStuff -> SeparateBagsDerivStuff f (DerivAuxBind _) = panic "genAuxBinds'" -- We have removed these before f (DerivHsBind b) = add1 b f (DerivFamInst t) = add2 t - f (DerivInst i) = add3 i - add1 x (a,b,c) = (x `consBag` a,b,c) - add2 x (a,b,c) = (a,x `consBag` b,c) - add3 x (a,b,c) = (a,b,x `consBag` c) + add1 x (a,b) = (x `consBag` a,b) + add2 x (a,b) = (a,x `consBag` b) mkParentType :: TyCon -> Type -- Turn the representation tycon of a family into _______________________________________________ ghc-commits mailing list ghc-commits(a)haskell.org https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskel…

1 0

Action Required: Status of Harbormaster for Differentials
by Ben Gamari 30 Aug '16

30 Aug '16

tl;dr. I am working on restoring Harbormaster support for Differentials. Towards this end, GHC's Phabricator instance will soon require that you add an SSH public key to your account in order to upload patches with `arc diff`. Hello everyone, As you are no doubt aware Harbormaster has not been building Differentials for a very long time now. I am currently looking at options for restoring this service but it appears that doing so will require a bit of action on the part of our contributors. Specically, you will need to add an SSH key to Phabricator. You can do so by navigating to the Phabricator Settings [1] page, selecting the "Personal Account Settings" option, and selecting "SSH Public Keys" from the list on the left. There you can click on the "SSH Key Actions" menu on the top-right corner and click on the "Upload Public Key" item. Here you can specify a key name and paste the key contents (e.g. the contents of $HOME/.ssh/id_rsa.pub). The reason for this new requirement is that `arc diff` will soon push submitted diffs to a "staging area", a Git repository managed by Phabricator containing a branch for each submitted Differential. This will allow more reliable Harbormaster builds and merges as we will no longer need to rely on Phabricator correctly applying Differential patches (which has historically been problematic, especially for Differentials where the base commit is unavailable). If there are no objections, I would like to enable the staging area for the rGHC repository in three days, on Monday, 29 August 2016. After this date `arc diff` will try to push submitted differentials to the staging area, which will require a public key. Note, however, that pushing to the staging area can always be disabled with `arc diff`'s `--skip-staging` flag (although we won't be able to run CI builds on Differentials submitted in this way). To be clear: I would have liked to provide an option that did not require key-based authentication, but sadly neither Phabricator nor Gitolite provide any such option. I apologize for the added friction that this new requirement imposes. If enough people feel strongly that this is too onerous then I'm happy to entertain alternative solutions. Cheers, - Ben [1] https://phabricator.haskell.org/settings/

5 12

Trying to refactor DeriveAnyClass, stuck on typechecker-related code
by Ryan Scott 28 Aug '16

28 Aug '16

Simon, I'm currently working on a solution to #12144, which changes the way inferred contexts for DeriveAnyClass works, as per your suggestion here [1]. I've made some good progress in that instances derived using DeriveAnyClass now emit contexts that are gathered from the default signatures of the derived class itself. However, I've come to an impasse. This approach currently fails to work with most GHC Generics-style classes, for reasons that I'll explain below. Consider this example (abridged from here [2]): data StrictMaybe a = StrictNothing | StrictJust !a deriving (FullyStrict, Generic) class FullyStrict a where fullyStrict :: proxy a -> Bool default fullyStrict :: (GFullyStrict (Rep a)) => proxy a -> Bool fullyStrict _ = gfullyStrict (Proxy :: Proxy (Rep a p)) With the new approach, the derived FullyStrict instance for StrictMaybe a will emit the context (GFullyStrict (Rep (StrictMaybe a)), but then fail with the error: No instance for (GFullyStrict (Rep (StrictMaybe a)) I think I understand why this is happening: if you look at the definition of tcDeriving in TcDeriv [3], it calls simplifyInstanceContexts, which would normally reduce type families like Rep. But the problem is that the Rep (StrictMaybe a) instance is also being derived at the same time (via the derived Generic instance)! What's worse, the call to simplifyInstanceContexts happens before the code that adds Rep (StrictMaybe a) to the type family instance environment (tcExtendLocalFamInstEnv (bagToList famInsts)). So simplifyInstanceContexts is unable to reduce Rep (StrictMaybe a), and as a result the context fails to simplify, resulting in the above error. This leads me to think we need to be adding Rep (StrictMaybe a) to the instance environment before calling simplifyInstanceContexts. But with the way the code is structured currently, I don't see an easy way to do this. The problem is that the genInst function [4] generates all of the following at the same time in one large bundle: * The instance code itself (InstInfo RdrName) * The associated type family instances (BagDerivStuff) * Auxiliary top-level bindings (BagDerivStuff) And within tcDeriving, the call to genInst takes as input the output of simplifyInstanceContexts, making it impossible to get the type family instances before calling simplifyInstanceContexts. Here are my questions: is it possible to take type family instances out of BagDerivStuff and instead add them to the instance environment before simplifyInstanceContexts? Would there be any typechecking issues involved with having the associated family instances in the local environment before the actual class instances themselves? Ryan S. ----- [1] https://mail.haskell.org/pipermail/ghc-devs/2016-June/012276.html [2] http://git.haskell.org/ghc.git/blob/0050aff22ba04baca732bf5124002417ab667f8… [3] http://git.haskell.org/ghc.git/blob/0050aff22ba04baca732bf5124002417ab667f8… [4] http://git.haskell.org/ghc.git/blob/0050aff22ba04baca732bf5124002417ab667f8…

2 2

RE: [Diffusion] [Build Failed] rGHCae66f356fb0d: Allow typed holes to be levity-polymorphic
by Simon Peyton Jones 26 Aug '16

26 Aug '16

Ben or others Something is wrong with the .stderr file for T12531 (typed holes), which I just fixed. Not easy for me to sort out at home..might someone look? Or mark it as expect fail and I'll deal with it on Monday Thanks Simon From: noreply(a)phabricator.haskell.org [mailto:noreply@phabricator.haskell.org] Sent: 26 August 2016 18:24 To: Simon Peyton Jones <simonpj(a)microsoft.com> Subject: [Diffusion] [Build Failed] rGHCae66f356fb0d: Allow typed holes to be levity-polymorphic Harbormaster failed to build B10796: rGHCae66f356fb0d: Allow typed holes to be levity-polymorphic! BRANCHES master USERS simonpj (Author) O7 (Auditor) O11 (Auditor) COMMIT https://phabricator.haskell.org/rGHCae66f356fb0d EMAIL PREFERENCES https://phabricator.haskell.org/settings/panel/emailpreferences/ To: simonpj, Harbormaster

1 0

Trac commit notifications on stable branches
by Ben Gamari 26 Aug '16

26 Aug '16

Hello everyone, For a long time we've had a Git hook which adds comments to Trac tickets mentioned in commits on the master branch. Today I enabled similar notifications for the commits on the stable branches (e.g. ghc-8.0) in an attempt at reducing the overhead of maintaining the stable branches. Please let me know if you find these additional notifications too noisy. Cheers, - Ben

2 3