- ghc-devs - Haskell.org

HEADS UP: linker symbols changed, need to recompile
by Edward Z. Yang 05 Aug '14

05 Aug '14

I've just pushed a set of patches which change the linker symbols GHC chooses for object files; you'll need to make clean and rebuild your tree once you take these changes. Thanks, Edward

1 0

Status updates
by Austin Seipp 05 Aug '14

05 Aug '14

Hi *, Here's some weekly status updates! - I'm merging Applicative-Monad today after a few more minor fixes. OMG YES. This only occurred after fighting off some nasty bugs that took quite a while to track down. Unfortunately this ate up most of my time this week. - I redid the Phabricator page quite a bit on the wiki, as I sent in my earlier email. Do read over it and let me know what you think, I'll be updating it more soon: https://ghc.haskell.org/trac/ghc/wiki/Phabricator - I'm going to be redoing the Git wiki pages a bit today to streamline them, which hopefully will only take a few hours. - I'm draining the patch queue still, both from Phabricator and Trac, although I need to re-triage a few of the Trac tickets in particular which are in 'patch' status. - We have a new committer afoot, Karel Gardas! Yay! He's been working on Solaris support, so having direct access to commit will surely help speed things up here. - DPH will soon be disabled by default in ./validate, although Geoff has stepped up to help alleviate some of the pain (see prior emails from me.) After all that: - I'm going to fix bugs! Yes, I'll actually have time to do that. - Sometime this week I'll also hopefully finish off my Phabricator integrations: better build bot, with accurate logs, and posting to Trac from Phabricator. This is *almost* done, but still needs to be tested/deployed a bit. - I may get around to finally pushing my patches for faster inline copies this week (and -march support) if I still have time. Do let me know if anything is on your mind, or if any of you have questions. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

2 2

Phabricator updates
by Austin Seipp 04 Aug '14

04 Aug '14

Hello *, I've spent the morning re-jiggering our Phabricator documentation: https://ghc.haskell.org/trac/ghc/wiki/Phabricator It now includes: - More screenshots! - Coverage of core applications, including Owners, and better coverage of Herald - Coverage of the new remarkup syntax - Better tips - Linking issues in Phabricator to Trac issues I particularly think people will find 'Owners' very useful, in combination with Herald. I have already organized a lot of the GHC source tree into 'Owner packages' and assigned owners. If you're working on the compiler, please go tweak those and add yourself as an owner of some part of the compiler! In particular the last one is the one you'll want to note the most. When you run `arc diff` now, you can associate a differential revision with a ticket. Here's the documentation with a nice big screenshot: https://ghc.haskell.org/trac/ghc/wiki/Phabricator#Linkingtracticketsandwiki… The TL;DR is when you run `arc diff`, just fill out the new "GHC Trac Issues" field and it'll be linked. As a bonus, it'll automatically show up in commit messages, and be hyperlinked in Phabricator appropriately. Note: Phabricator does not yet comment on Trac still, sorry. I didn't get around to it this week. Please let me know if anything is confusing. I'm sure I need to expand on stuff; in particular I still need to do another pass, adding some screenshots for Audit, and some of the "Philosophy of Phabricator" on how you may want to submit reviews and think about organizing your work. Thanks. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

2 1

Release building for Windows
by Mark Lentczner 04 Aug '14

04 Aug '14

Randy Polen, undertook porting the new build of Haskell Platform to Windows. He did a great job... but as this is first time stepping up to such a big release, he has some questions about GHC and Windows, and the choices he had to make. He asked me to forward these to this list, as he's not a member. He's cc'd so you can reply to all and include him... or I can forward as needed. >From Randy: ------------------ I am building the Haskell Platform 2014.2.0.0 on the Windows side. Your advice would be very helpful to make sure the HP 2014 for Windows is as good as possible. There were some issues I worked-around, plus some features that seem to not be available in this particular GHC (7.8.3) on the 32-bit and 64-bit Windows platforms, and I would like to confirm that HP 2014.2.0.0 will be shipping something sensible and as expected for the Windows environment, noting things which are supported on other environments but not on Windows. * GHC 7.8.3 on Windows does not support building Haskell into shared libraries, (GHC ticket #8228) so all packages in HP 2014.2.0.0 for Windows have been built without --enable-shared * GHC 7.8.3 on Windows does not currently support LLVM (GHC ticket #7143) * All Windows HP 2014.2.0.0 packages have been built without --enabled-split-objs, in deference to the GHC 7.8 FAQ * Extra python, etc. bits included in the GHC 7.8.3 bindist for 64-bit Windows (GHC issue #9014) are not installed with Windows HP 2014.2.0.0. Is eliding them from the HP 2014.2.0.0 64-bit Windows installation safe and correct (i.e., are they truely not required)? * Missing src/html in GHC packages were worked around by replacing the entire GHC package doc tree of html files with the contents of the "Standard Libraries" tarball (but not for the two packages which are not built for Windows, terminfo and unix). Is this valid to do? Any issues might arise? * ref: http://www.haskell.org/ghc/docs/latest/libraries.html.tar.bz2 Thanks for any advice on these. I do want to make the Windows HP 2014.2.0.0 be as good as it can be. Randy

4 6

Question about BangPatterns semantics/documentation
by Herbert Valerio Riedel 04 Aug '14

04 Aug '14

The GHC User's Guide[1] says: | There is one (apparent) exception to this general rule that a bang | only makes a difference when it precedes a variable or wild-card: a | bang at the top level of a let or where binding makes the binding | strict, regardless of the pattern. (We say "apparent" exception | because the Right Way to think of it is that the bang at the top of a | binding is not part of the pattern; rather it is part of the syntax of | the binding, creating a "bang-pattern binding".) For example: | | let ![x,y] = e in b | | is a bang-pattern binding. Operationally, it behaves just like a case | expression: | | case e of [x,y] -> b However, the following two functions are not equivalent after compilation to Core: g, h :: (Int -> Int) -> Int -> () g f x = let !y = f x in () h f x = case f x of y -> () In fact, compilation results in g = \ (f_asi :: Int -> Int) (x_asj :: Int) -> case f_asi x_asj of _ [Occ=Dead] { I# ipv_sKS -> () } h = \ _ [Occ=Dead] _ [Occ=Dead] -> () Is the documentation inaccurate/incomplete/I-missed-something or is the implementation to blame? Cheers, hvr [1]: http://www.haskell.org/ghc/docs/7.8.3/html/users_guide/bang-patterns.html

3 2

HEADS UP: Applicative-Monad incoming
by Austin Seipp 04 Aug '14

04 Aug '14

Hi all, The Applicative Monad changes will be landing in HEAD soon, hopefully within a few hours once ./validate finishes and I triple-check everything. Why am I sending this? To warn you that you need to update Happy to *at least* version 1.19.4 before you can build GHC again. This is because Happy emitted parsers that had instances of Monad, and thus Happy needed to be fixed to also emit Applicative instances. Please be sure to upgrade your workstations, buildbots, toasters, etc so you don't get caught by surprise. ./configure will fail you if your Happy is invalid. This message is brought to you by sleep deprivation and almost two days of hunting an infinite loop in my changeset, which was quite annoying to track down. I'm sure something will still go wrong during ./validate... -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

globalRegMaybe and ARM
by Ben Gamari 04 Aug '14

04 Aug '14

Hello Simon, b0534f7 [1] and the subsequent reversion f0fcc41d7 touched `includes/CodeGen.Platform.hs`, the former removing a panic in the case of `globalRegMaybe` being undefined for a platform and replacing it with `Nothing`. Recently I've found that my ARM builds (with -fllvm) crash at this panic whereas they did not as of the 7.8 release. Given that b0534f7 was reverted this is no doubt due to another change that I haven't identified yet. Do you have any idea what is happening here? I'm currently attempting to build with a workaround setting `globalRegMaybe _ = Nothing`, although this smells suspicously like what would happen in the unregisterized case. My other hypothesis is that MACHREGS_arm should be added to the #if MACHREGS_i386 || MACHREGS_x86_64 || MACHREGS_sparc || MACHREGS_powerpc which smells more like what a registerised architecture should do and it seems the requisite macros are defined for ARM in `stg/MachRegs.h`. Whatever happens for ARM should probably also happen for AArch64. How should `globalRegMaybe` and `freeReg` be defined for platforms that rely exclusively on the LLVM backend? Both ARM and AArch64 appear to be doing the wrong thing at present. Cheers, - Ben [1] https://github.com/ghc/ghc/commit/b0534f78a73f972e279eed4447a5687bd6a8308e#…

2 1

RE: [commit: ghc] master: Dont allow hand-written Generic instances in Safe Haskell. (578fbec)
by Simon Peyton Jones 04 Aug '14

04 Aug '14

David Thanks for doing this. I'm a bit concerned, though, that there is quite a bit of Safe-Haskell special-casing in GHC, but no single place to look for a list of what the choices are, and why they are made. Even the paragraph you wrote as a commit comment would make a helpful Note to accompany the code changes. The worry is that in five years time someone will look at this code and wonder "why exactly is this special case there?". They may look in the paper, but Generics post-dates it. Would it be worth Wiki page to collect the choices? Or more detailed Notes with the individual tests? Thanks Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf Of | git(a)git.haskell.org | Sent: 02 August 2014 03:06 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] master: Dont allow hand-written Generic | instances in Safe Haskell. (578fbec) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : master | Link : | http://ghc.haskell.org/trac/ghc/changeset/578fbeca31dd3d755e24e910c3a73 | 27f92bc4ee3/ghc | | >--------------------------------------------------------------- | | commit 578fbeca31dd3d755e24e910c3a7327f92bc4ee3 | Author: David Terei <code(a)davidterei.com> | Date: Thu Dec 5 17:27:17 2013 -0800 | | Dont allow hand-written Generic instances in Safe Haskell. | | While they aren't strictly unsafe, it is a similar situation to | Typeable. There are few instances where a programmer will write | their | own instance, and having compiler assurance that the Generic | implementation is correct brings a lot of benefits. | | | >--------------------------------------------------------------- | | 578fbeca31dd3d755e24e910c3a7327f92bc4ee3 | compiler/prelude/PrelNames.lhs | 3 +++ | compiler/typecheck/TcInstDcls.lhs | 31 +++++++++++++++++++++---------- | 2 files changed, 24 insertions(+), 10 deletions(-) | | diff --git a/compiler/prelude/PrelNames.lhs | b/compiler/prelude/PrelNames.lhs index 2c84e40..b2dec88 100644 | --- a/compiler/prelude/PrelNames.lhs | +++ b/compiler/prelude/PrelNames.lhs | @@ -1084,6 +1084,9 @@ datatypeClassName = clsQual gHC_GENERICS | (fsLit "Datatype") datatypeClassK | constructorClassName = clsQual gHC_GENERICS (fsLit "Constructor") | constructorClassKey | selectorClassName = clsQual gHC_GENERICS (fsLit "Selector") | selectorClassKey | | +genericClassNames :: [Name] | +genericClassNames = [genClassName, gen1ClassName] | + | -- GHCi things | ghciIoClassName, ghciStepIoMName :: Name ghciIoClassName = clsQual | gHC_GHCI (fsLit "GHCiSandboxIO") ghciIoClassKey diff --git | a/compiler/typecheck/TcInstDcls.lhs b/compiler/typecheck/TcInstDcls.lhs | index c3ba825..6ff8a2b 100644 | --- a/compiler/typecheck/TcInstDcls.lhs | +++ b/compiler/typecheck/TcInstDcls.lhs | @@ -51,8 +51,8 @@ import VarEnv | import VarSet | import CoreUnfold ( mkDFunUnfolding ) | import CoreSyn ( Expr(Var, Type), CoreExpr, mkTyApps, mkVarApps ) | -import PrelNames ( tYPEABLE_INTERNAL, typeableClassName, | oldTypeableClassNames ) | - | +import PrelNames ( tYPEABLE_INTERNAL, typeableClassName, | + oldTypeableClassNames, genericClassNames ) | import Bag | import BasicTypes | import DynFlags | @@ -415,13 +415,16 @@ tcInstDecls1 tycl_decls inst_decls deriv_decls | -- hand written instances of old Typeable as then unsafe casts | could be | -- performed. Derived instances are OK. | ; dflags <- getDynFlags | - ; when (safeLanguageOn dflags) $ | - mapM_ (\x -> when (typInstCheck x) | - (addErrAt (getSrcSpan $ iSpec x) | typInstErr)) | - local_infos | + ; when (safeLanguageOn dflags) $ forM_ local_infos $ \x -> case | x of | + _ | typInstCheck x -> addErrAt (getSrcSpan $ iSpec x) | (typInstErr x) | + _ | genInstCheck x -> addErrAt (getSrcSpan $ iSpec x) | (genInstErr x) | + _ -> return () | + | -- As above but for Safe Inference mode. | - ; when (safeInferOn dflags) $ | - mapM_ (\x -> when (typInstCheck x) recordUnsafeInfer) | local_infos | + ; when (safeInferOn dflags) $ forM_ local_infos $ \x -> case x | of | + _ | typInstCheck x -> recordUnsafeInfer | + _ | genInstCheck x -> recordUnsafeInfer | + _ -> return () | | ; return ( gbl_env | , bagToList deriv_inst_info ++ local_infos @@ -442,8 | +445,16 @@ tcInstDecls1 tycl_decls inst_decls deriv_decls | else (typeableInsts, i:otherInsts) | | typInstCheck ty = is_cls_nm (iSpec ty) `elem` | oldTypeableClassNames | - typInstErr = ptext $ sLit $ "Can't create hand written instances | of Typeable in Safe" | - ++ " Haskell! Can only derive them" | + typInstErr i = hang (ptext (sLit $ "Typeable instances can only be | " | + ++ "derived in Safe Haskell.") $+$ | + ptext (sLit "Replace the following | instance:")) | + 2 (pprInstanceHdr (iSpec i)) | + | + genInstCheck ty = is_cls_nm (iSpec ty) `elem` genericClassNames | + genInstErr i = hang (ptext (sLit $ "Generic instances can only be | " | + ++ "derived in Safe Haskell.") $+$ | + ptext (sLit "Replace the following | instance:")) | + 2 (pprInstanceHdr (iSpec i)) | | instMsg i = hang (ptext (sLit $ "Typeable instances can only be | derived; replace " | ++ "the following instance:")) | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-commits

1 0

GHC.Event.Unique vs Data.Unique
by Michael Schröder 02 Aug '14

02 Aug '14

Is there a reason GHC.Event.Unique exists, since we also have Data.Unique? Or is this just a historical artifact? It looks like they used to have the same implementation, but have now diverged, with Data.Unique being the more recent one. GHC.Event.Unique still uses STM internally, and is as far as I can see the only part of the base library to do so. Which wouldn't really matter, except that now basic IO stuff like threadDelay and even putStr (sometimes, especially in ghci) cannot be used inside unsafeIOToSTM. Which is somewhat annoying…

2 1

Overlapping and incoherent instances
by Simon Peyton Jones 02 Aug '14

02 Aug '14

Friends One of GHC's more widely-used features is overlapping (and sometimes incoherent) instances. The user-manual documentation is here<http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class-extensio…>. The use of overlapping/incoherent instances is controlled by LANGUAGE pragmas: OverlappingInstances and IncoherentInstances respectively. However the overlap/incoherent-ness is a property of the *instance declaration* itself, and has been for a long time. Using LANGUAGE OverlappingInstances simply sets the "I am an overlapping instance" flag for every instance declaration in that module. This is a Big Hammer. It give no clue about *which* particular instances the programmer is expecting to be overlapped, nor which are doing the overlapping. It brutally applies to every instance in the module. Moreover, when looking at an instance declaration, there is no nearby clue that it might be overlapped. The clue might be in the command line that compiles that module! Iavor has recently implemented per-instance-declaration pragmas, so you can say instance {-# OVERLAPPABLE #-} Show a => Show [a] where ... instance {-# OVERLAPPING #-} Show [Char] where ... This is much more precise (it affects only those specific instances) and it is much clearer (you see it when you see the instance declaration). This new feature will be in GHC 7.10 and I'm sure you will be happy about that. But I propose also to deprecate the LANGUAGE pragmas OverlappingInstances and IncoherentInstances, as way to encourage everyone to use the new feature instead of the old big hammer. The old LANGUAGE pragmas will continue to work, of course, for at least another complete release cycle. We could make that two cycles if it was helpful. However, if you want deprecation-free libraries, it will entail a wave of library updates. This email is just to warn you, and to let you yell if you think this is a bad idea. It would actually not be difficult to retain the old LANGUAGE pragmas indefinitely - it just seems wrong not to actively push authors in the right direction. These deprecations of course popped up in the test suite, so I've been replacing them with per-instance pragmas there too. Interestingly in some cases, when looking for which instances needed the pragmas, I found...none. So OverlappingInstances was entirely unnecessary. Maybe library authors will find that too! Simon

3 3