September 2018 - ghc-devs

[ANNOUNCE] GHC 8.6.1-beta1 available
by Ben Gamari 11 Sep '18

11 Sep '18

Hello everyone, The GHC development team is very pleased to announce the first beta leading up to GHC 8.6.1 release. The usual release artifacts are available from https://downloads.haskell.org/~ghc/8.6.1-beta1 This beta fixes most of the bugs reported in the first two alphas and brings all of the core libraries up to their final release versions. The 8.6 release fixes over 300 bugs from the 8.4 series and introduces a number of exciting features. These most notably include: * Significantly better handling of macOS linker command size limits, avoiding linker errors while linking large projects * A new deriving mechanism, `deriving via`, providing a convenient way for users to extend Haskell's typeclass deriving mechanism * Quantified constraints, allowing forall quantification in contexts * An early version of the GHCi `:doc` command * The `ghc-heap-view` package, allowing introspection into the structure of GHC's heap * Valid hole fit hints, helping the user to find terms to fill typed holes in their programs * The BlockArguments extension, allowing the `$` operator to be omitted in some unambiguous contexts * The next phase of the MonadFail proposal, enabling -XMonadFailDesugaring by default A full list of the changes in this release can be found in the release notes: https://downloads.haskell.org/~ghc/8.6.1-beta1/docs/html/users_guide/8.6.1-… This will very likely be the last release before the final 8.6.1 so do give it a thorough testing and, as always, report any issues you encounter. Thanks for your help! Cheers, - Ben

3 2

ForeignPtr representation
by David Feuer 06 Sep '18

06 Sep '18

I'm trying, and failing, to understand why ForeignPtr is defined the way it is. It all seems rather complicated and redundant. I was thinking we might want to switch to something simpler and more explicit, like this: data ForeignPtr a = ForeignPtr { fptr :: !(Ptr a) -- What we point to froot :: MutableByteArray# RealWorld fwk :: MutVar# RealWorld Any -- The finalizers } froot represents the object the ForeignPtr points into. When created by one of the malloc variants, this will actually be the allocated byte array. Otherwise, it will be a 0-length array. fwk should be seen as having type fwk :: MutVar# RealWorld (Weak# (MutableByteArray# RealWorld)) but we can't express that directly right now. fwk is keyed on froot, and in the malloc case also points to it, to prevent it from being freed prematurely. It seems that this representation requires a couple extra primitive features from Weak#. I think that's okay: Weak# already has some primitive features designed to support ForeignPtr. 1. An operation to add a Haskell finalizer to a Weak#, similar to the one that adds a C finalizer. 2. A way to deal with mixed finalizers: either make the finalizer-adding primops report distinguishable failure on mixing or arrange to run the C finalizers after any Haskell finalizers (since C finalizers are much more likely to actually invalidate the pointer). 3. A documented guarantee about the order in which the finalizers attached to a particular Weak# run, compatible with the ForeignPtr documentation.

3 3

Re: Unpacking coercions
by Ryan Scott 05 Sep '18

05 Sep '18

These aren't mutually exclusive ideas. While I'm sure there's many ways we could solve this problem, David's idea has the distinct advantage of being dead simple. I'd rather not block his vision on some other large refactor that may never materialize. (And if it _does_ materialize, we could revert any wiring-in of Coercible quite easily.) Ryan S.

3 6

Running GHC 7.10.2 on Ubuntu 18.04 ?
by Ömer Sinan Ağacan 05 Sep '18

05 Sep '18

Hi, I'm trying to use GHC 7.10.2 (the Debian 8 bindist from haskell.org) on Ubuntu 18.04. It's currently failing with linker errors when I compile `main = return ()`: /usr/bin/x86_64-linux-gnu-ld: /home/omer/ghc_bins/ghc-7.10.3-bin/lib/ghc-7.10.3/base_HQfYBxpPvuw8OunzQu6JGM/libHSbase-4.8.2.0-HQfYBxpPvuw8OunzQu6JGM.a(Base__5.o): relocation R_X86_64_32S against `.text' can not be used when making a PIE object; recompile with -fPIC /usr/bin/x86_64-linux-gnu-ld: /home/omer/ghc_bins/ghc-7.10.3-bin/lib/ghc-7.10.3/base_HQfYBxpPvuw8OunzQu6JGM/libHSbase-4.8.2.0-HQfYBxpPvuw8OunzQu6JGM.a(Base__125.o): relocation R_X86_64_32S against `.text' can not be used when making a PIE object; recompile with -fPIC /usr/bin/x86_64-linux-gnu-ld: /home/omer/ghc_bins/ghc-7.10.3-bin/lib/ghc-7.10.3/base_HQfYBxpPvuw8OunzQu6JGM/libHSbase-4.8.2.0-HQfYBxpPvuw8OunzQu6JGM.a(Signal__13.o): relocation R_X86_64_32S against `.text' can not be used when making a PIE object; recompile with -fPIC /usr/bin/x86_64-linux-gnu-ld: /home/omer/ghc_bins/ghc-7.10.3-bin/lib/ghc-7.10.3/base_HQfYBxpPvuw8OunzQu6JGM/libHSbase-4.8.2.0-HQfYBxpPvuw8OunzQu6JGM.a(Sync__199.o): relocation R_X86_64_32S against `.text' can not be used when making a PIE object; recompile with -fPIC /usr/bin/x86_64-linux-gnu-ld: /home/omer/ghc_bins/ghc-7.10.3-bin/lib/ghc-7.10.3/base_HQfYBxpPvuw8OunzQu6JGM/libHSbase-4.8.2.0-HQfYBxpPvuw8OunzQu6JGM.a(Exception__170.o): relocation R_X86_64_32S against symbol `stg_bh_upd_frame_info' can not be used when making a PIE object; recompile with -fPIC I'm getting about 700 of these. Does anyone know a way to make GHC 7.10.2 work on Ubuntu 18.04? Not sure if related but the ld version is ~ $ /usr/bin/x86_64-linux-gnu-ld --version GNU ld (GNU Binutils for Ubuntu) 2.30 Copyright (C) 2018 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) a later version. This program has absolutely no warranty. Thanks, Ömer

2 2

Re: Running GHC 7.10.2 on Ubuntu 18.04 ?
by Ryan Scott 05 Sep '18

05 Sep '18

This is likely caused by an old GHC bug that interacts poorly with newer version of binutils (I can't remember the exact bug, unfortunately). I personally use hvr's Ubuntu PPA [1] whenever installing GHC on Ubuntu. This PPA backports patches to old versions of GHC to keep them working with newer versions of binutils, and I can confirm that the version of GHC 7.10.2 offered from here works well with Ubuntu 18.04. Ryan S. ----- [1] https://launchpad.net/~hvr/+archive/ubuntu/ghc

1 0

Rational for the special case in mkWWcpr_help
by Spiwack, Arnaud 05 Sep '18

05 Sep '18

Dear all, The function mkWWcpr_help, which creates a wrapper and a worker after strictness analysis, has a special case when there is a single result of unlifted type: Wrapper: case (..call worker..) of x -> C x Worker: case ( ..body.. ) of C x -> x But I don't understand how it is different from using (# #) as would result from the general case: Wrapper: case (..call worker..) of (# x #) -> C x Worker: case ( ..body.. ) of C x -> (# x #) That is, my understanding of the latter is that it would yield the exact same code. I'm obviously missing something, I'd love to know what. Best, Arnaud

2 1

Does tyCoVarsOfTypesList guarantee a particular order?
by Ryan Scott 05 Sep '18

05 Sep '18

tyCoVarsOfTypesList guarantees that it returns its answer in a deterministic order. For the longest time, I must have assumed that this order was left to right. However, it appears that my assumption was wrong! This can be demonstrated with this program: module Main where import Name import TyCoRep import TysPrim import Var main :: IO () main = do putStrLn "(1)" print $ map (getOccString . tyVarName) $ tyCoVarsOfTypesList [TyVarTy alphaTyVar, TyVarTy betaTyVar] putStrLn "(2)" print $ map (getOccString . tyVarName) $ tyCoVarsOfTypesList [TyVarTy alphaTyVar, TyVarTy betaTyVar, TyVarTy alphaTyVar] This gives the following output: (1) ["a","b"] (2) ["b","a"] The first one makes total sense to me. The second, one however, does not. If the free variables of that list were returned in left-to-right order (or even right-to-left order!), then (2) should give the same answer as (1). Instead, it lists "b" _before_ "a", which I find incredibly baffling. To explain why I care so much about this, we're currently trying to improve Haddock's logic for choosing when to put explicit `forall`s in front of types [1]. Our litmus test is this: if the order in which a user wrote the `forall`d variables differs from the order in which the free variables of the body would normally occur, then have Haddock display an explicit forall. I would have assumed that tyCoVarsOfTypesList [2] would be enough to determine the "normal" order of the free variables, but as the example above proves, this sometimes gives unexpected orderings when there are multiple occurrences of the same variable. We are currently having to work around this issue [1] by implementing our own custom versions of tyCoFVsOfType and friends that accumulate variables in reverse order (and then reversing the list at the end!) to get the order we expect. This feels incredibly wasteful to me, so I'd like to know if there's a better way. In particular: 1. Is this behavior of tyCoVarsOfTypesList expected? 2. If not, should we change it? Ryan S. ----- [1] See https://github.com/haskell/haddock/pull/931 [2] Actually, I would use tyCoVarsOfTypesWellScoped, but dependency order doesn't come into play in the example I gave above.

2 1

Re: Unpacking coercions
by Ryan Scott 04 Sep '18

04 Sep '18

In case this wasn't clear, the context of this discussion in this GHC proposal [1], where David is trying to work around the fact that data types with existential Coercible constraints do not support unpacking. (By "unpacking", I mean putting an {-# UNPACK #-} pragma in front of a field of that type does what you would expect.) An example program which demonstrates the performance issue can be found here [2]. That comment concerns unboxed equality vs. boxed equality, but the same unpacking problems that affect boxed equality also affect Coercible. Ryan S. ----- [1] https://github.com/ghc-proposals/ghc-proposals/pull/116 [2] https://github.com/ghc-proposals/ghc-proposals/pull/116#issuecomment-382346…

2 1

RE: Hadrian
by Andrey Mokhov 04 Sep '18

04 Sep '18

Thanks Simon, I fixed the "verboseCommands" typo. Regarding various available predicates: indeed, we don't currently have a comprehensive description -- I've opened an issue for this and will hopefully fix it soon. In the meanwhile, there are a few examples of predicates in the rest of the doc/user-settings.md document, for example here: https://github.com/snowleopard/hadrian/blob/master/doc/user-settings.md#com…. The `input` and `output` predicates accept Shake's `FilePattern` as parameters -- see the documentation for it here: https://hackage.haskell.org/package/shake-0.16.4/docs/Development-Shake.htm… Cheers, Andrey -----Original Message----- From: Simon Peyton Jones [mailto:simonpj@microsoft.com] Sent: 04 September 2018 16:49 To: Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk>; Alp Mestanogullari <alp(a)well-typed.com> Cc: ghc-devs <ghc-devs(a)haskell.org> Subject: RE: Hadrian Very confusingly https://github.com/snowleopard/hadrian/blob/master/doc/user-settings.md#ver… speaks about verboseCommmands PLURAL, whereas it should say verboseCommand SINGLUAR. Moreover, what is the language things you can say (i.e. where is it documented). The "//" business, and what patterns can occur. What things other than "//" can you have? What about 'input' etc? Simon | -----Original Message----- | From: Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk> | Sent: 30 August 2018 12:26 | To: Simon Peyton Jones <simonpj(a)microsoft.com>; Alp Mestanogullari | <alp(a)well-typed.com> | Cc: ghc-devs <ghc-devs(a)haskell.org> | Subject: RE: Hadrian | | Simon, | | If you want to see all command lines, you can pass '--verbose' or '-V' | flag to Hadrian and it will then print out everything it does. | | But you can also choose which particular command lines to print in | UserSettings, see: | | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c | om%2Fsnowleopard%2Fhadrian%2Fblob%2Fmaster%2Fdoc%2Fuser- | settings.md%23verbose-command- | lines&data=02%7C01%7Csimonpj%40microsoft.com%7C0c6118a504f74269efd508 | d60e6b4fe7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63671225140342623 | 1&sdata=tMYhmIGMeVbBYjAtxWQTY5%2F4Kyfc4m981N4OTowGkbQ%3D&reserved | =0 | | So, you can do: | | verboseCommand = input "//GHC/Real.hs" | | Or, alternatively, | | verboseCommand = output "//GHC/Real.hi" | | Both should produce the same result (in theory). | | In general, we have the following documents on Hadrian: | | The README: | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c | om%2Fsnowleopard%2Fhadrian%2Fblob%2Fmaster%2FREADME.md&data=02%7C01%7 | Csimonpj%40microsoft.com%7C0c6118a504f74269efd508d60e6b4fe7%7C72f988bf86f | 141af91ab2d7cd011db47%7C1%7C0%7C636712251403426231&sdata=7WigmQG7lbDd | eyhYCSaKOQEb0eeZcn0iXAbAKdwZ5A4%3D&reserved=0 | How to use UserSettings: | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c | om%2Fsnowleopard%2Fhadrian%2Fblob%2Fmaster%2Fdoc%2Fuser- | settings.md&data=02%7C01%7Csimonpj%40microsoft.com%7C0c6118a504f74269 | efd508d60e6b4fe7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63671225140 | 3426231&sdata=tRu2lO%2F6TNV3ao5tzNKO%2FAHJMWsxKX%2BqExHn78nuCvU%3D&am | p;reserved=0 | An overview of build flavours: | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c | om%2Fsnowleopard%2Fhadrian%2Fblob%2Fmaster%2Fdoc%2Fflavours.md&data=0 | 2%7C01%7Csimonpj%40microsoft.com%7C0c6118a504f74269efd508d60e6b4fe7%7C72f | 988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636712251403426231&sdata=Esye | DdAKLV9DC3PUwkqsuQ4zGoOYKcaJeEov1BAH8lU%3D&reserved=0 | | I hope the more Hadrian gets used, the more complete the documentation | will become. | | Cheers, | Andrey | | From: Simon Peyton Jones [mailto:simonpj@microsoft.com] | Sent: 30 August 2018 12:19 | To: Simon Peyton Jones <simonpj(a)microsoft.com>; Alp Mestanogullari | <alp(a)well-typed.com>; Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk> | Cc: ghc-devs <ghc-devs(a)haskell.org> | Subject: RE: Hadrian | | Sigh. As an inconvenient workaround, I tried adding {-# OPTIONS_GHC - | dverbose-core2core #-} to GHC.Real, and then doing | cabal new-run hadrian -- -c -j4 --flavour=quick --directory=".." | in hadrian/ | That did recompile GHC.Real - but all the debug output disappeared! | I tried adding {-# OPTIONS_GHC -ddebug-output #-} as well, but that | didn't work. | I'm stuck - any ideas? | Simon | | From: ghc-devs <ghc-devs-bounces(a)haskell.org> On Behalf Of Simon Peyton | Jones via ghc-devs | Sent: 30 August 2018 12:12 | To: Alp Mestanogullari <alp(a)well-typed.com>; Andrey Mokhov | <andrey.mokhov(a)newcastle.ac.uk> | Cc: ghc-devs <ghc-devs(a)haskell.org> | Subject: Hadrian | | Alp, Andrey | The old build system printed out every command line; and I often copy- | paste that info to build single modules. | Eg currently, when trying to understand #15570 I see a suspicious | GHC.Real.hi. So I want to manually recompile GHC.Real (from base), | adding some debug flags. How can I get the right command line to do that | from the build log? | Where is the "how to use Hadrian" wiki page? I know you've been writing | one. | Simon

2 1

Is combining StaticPointers and TemplateHaskell safe?
by Matthew Pickering 04 Sep '18

04 Sep '18

I can implement a function which acts like `lift` using static pointers in the following way: ``` liftS :: StaticPtr a -> Q (TExp a) liftS sp = let sk = staticKey sp in [|| deRefStaticPtr (fromJust (unsafePerformIO (unsafeLookupStaticPtr sk))) ||] ``` The question, is this safe in general? It seems to me that this referencing should be safe because I could have achieved the same without quoting using `deRefStaticPtr` directly. The only reason I have to use the `unsafeLookup` function is because `StaticPtr` is not an instance of `Lift`. However, it's a bit annoying that this lookup has to be deferred to runtime, would it be acceptable to add an extra field to `StaticPtr a` which contained a `TExp a` value? Then the implementation of `liftS` just extracts this value from the `StaticPtr`. Using `static` is preferable to using `lift` in many situations as `Lift` is implemented using a type class it can't lift things such as 1. functions and 2. top-level identifiers. Further to this, it's annoying to have to incur a `Lift a` constraint when trying to lift `Nothing`. `static` has none of these problems. Cheers, Matt

2 1