- ghc-devs - Haskell.org

8.2.1: Ord TyCon is gone?
by Levent Erkok 29 Jul '17

29 Jul '17

I'm trying to port some plugin code from GHC 8.0.2 to GHC 8.2.1; alas I'm getting an error suggesting that TyCon is no longer an instance of Ord: Data/SBV/Plugin/Analyze.hs:580:33: error: • No instance for (Ord TyCon) arising from a use of ‘M.lookup’ There are instances for similar types: instance Ord GHC.Types.TyCon -- Defined in ‘GHC.Classes’ • In the expression: k `M.lookup` tcMap In the expression: case k `M.lookup` tcMap of Just knd -> return knd Nothing -> unknown In a case alternative: Just k -> case k `M.lookup` tcMap of Just knd -> return knd Nothing -> unknown | 580 | Just k -> case k `M.lookup` tcMap of | ^^^^^^^^^^^^^^^^^^ I was using TyCon's as a key in a map, but that code is no longer compiling. I've looked through the release notes but couldn't find what the new mechanism is. I'd appreciate if someone can point me in the right direction regarding how to use TyCon as a map key.. Thanks, -Levent.

6 7

[ANNOUNCE] GHC 8.2.1 available
by Ben Gamari 27 Jul '17

27 Jul '17

=============================================== The Glasgow Haskell Compiler -- version 8.2.1 =============================================== The GHC developers are very happy to announce the long-awaited 8.2.1 release of Glasgow Haskell Compiler. Binary and source distributions can be found at https://downloads.haskell.org/~ghc/8.2.1/ This is the second release in the 8.0 series. As such, the focus of this release is performance, stability, and consolidation. Consequently numerous cleanups can be seen throughout the compiler including, * Significant improvements in compiler performance * More robust support for levity polymorphism * Reliable DWARF debugging information * Improved runtime system performance on NUMA systems * Retooling of the cost-center profiler, including support for live streaming of profile data via the GHC event log * Interface file determinism * More robust treatment of join points, enabling significantly better code generation in many cases * Numerous improvements in robustness on Windows * and the resolution of over 500 other tickets In addition, there are a number of new features, * A new, more type-safe type reflection mechanism * The long-awaited Backpack module system * Deriving strategies to disambiguate between GHC's various instance deriving mechanisms * Unboxed sum types, for efficient unpacked representation of sum data types * Compact regions, allowing better control over garbage collection in the presence of large heaps containing many long-lived objects. * Colorful messages and caret diagnostics for more legible errors A more thorough list of the changes in this release can be found in the release notes, https://haskell.org/ghc/docs/8.2.1/docs/html/users_guide/8.2.1-notes.html There are a few changes in release-engineering that should be noted, * Binary distributions for 32-bit CentOS 6.7 have been dropped. Moreover, there are no dedicated CentOS 7.0 distributions as CentOS 7 can use can use Debian 8 binaries. If you would like us to continue to produce 32-bit CentOS 6.7 distributions please let us know. * GHC HQ now builds FreeBSD and OpenBSD distributions for amd64; this comes after many years of these distributions being faithfully provided by Karel Gardas and Pali Gabor Janos, who we should heartily thank for their contributions. GHC HQ building these distributions ourselves will allow us to more quickly ship distributions to users by eliminating the need for a long lag time between source release availability and having all binary distributions available. * There is a technology-preview of an AArch64 Linux binary distribution, as well as an ARM Linux build. AArch64 support is quite preliminary but should be stable in 8.4 thanks to further linker fixes by Moritz Angerman. ARM should be stable. * GHC now tries to use the gold and lld linkers by default. These linkers are significantly faster than the BFD linker implementation that most Linux distributions use by default. If gold or lld are not available GHC will use the system's default linker. GHC can be forced to use the default linker by passing --disable-ld-override to configure. This release has been the result of over a year of hard work by over 150 code contributors. Thanks to everyone who has helped in writing patches, testing, reporting bugs, and offering feedback over the last year. This release cycle was admittedly quite drawn out, significantly longer than expected or desired. While we are confident that the result is worth the wait, we have been steadily working on infrastructure which should help shrink future release cycles and give us better testing between releases. More details on this coming soon. As always, let us know if you encounter trouble. How to get it ~~~~~~~~~~~~~ The easy way is to go to the web page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating efficient code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces. GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ GHC developers' home page http://ghc.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, is here: http://ghc.haskell.org/trac/ghc/wiki/Contributors Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://ghc.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: http://ghc.haskell.org/trac/ghc/ Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see https://mail.haskell.org/cgi-bin/mailman/listinfo Some GHC developers hang out on #haskell on IRC, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug

4 6

Harbormaster update
by Ben Gamari 27 Jul '17

27 Jul '17

Hello everyone, Note that the Harbormaster builders now bootstrap with GHC 8.2.1 and LLVM 3.9. I'll be on the lookout for any failures but ping me if you see Harbormaster fail to build your otherwise perfectly good patch. Cheers, - Ben

1 0

RE: [commit: ghc] master: Improve error messages around kind mismatches. (8e15e3d)
by Simon Peyton Jones 27 Jul '17

27 Jul '17

| typecheck/should_fail/T7368) Solution: track the provenance of | Derived constraints and refuse to float out a constraint that has | an insoluble Derived. For the record, that's not the solution that the patch implements. Instead we just don’t float heterogeneous equalities. I think Richard just forgot to update the commit message. Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf | Of git(a)git.haskell.org | Sent: 27 July 2017 12:50 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] master: Improve error messages around kind | mismatches. (8e15e3d) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : master | Link : | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.ha | skell.org%2Ftrac%2Fghc%2Fchangeset%2F8e15e3d370e9c253ae0dbb330e25b72cb | 00cdb76%2Fghc&data=02%7C01%7Csimonpj%40microsoft.com%7C9993301a429e467 | e29b008d4d4e6350f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6363675 | 32584262688&sdata=bY%2Bruj0hhXfC23hfMA1ivuAs2Av2%2BY4%2BJK2yyCoPzbA%3D | &reserved=0 | | >--------------------------------------------------------------- | | commit 8e15e3d370e9c253ae0dbb330e25b72cb00cdb76 | Author: Richard Eisenberg <rae(a)cs.brynmawr.edu> | Date: Thu Jun 1 17:27:14 2017 -0400 | | Improve error messages around kind mismatches. | | Previously, when canonicalizing (or unifying, in uType) a | heterogeneous equality, we emitted a kind equality and used the | resulting coercion to cast one side of the heterogeneous equality. | | While sound, this led to terrible error messages. (See the bugs | listed below.) The problem is that using the coercion built from | the emitted kind equality is a bit like a wanted rewriting a | wanted. | The solution is to keep heterogeneous equalities as irreducible. | | See Note [Equalities with incompatible kinds] in TcCanonical. | | This commit also removes a highly suspicious switch to | FM_SubstOnly | when flattening in the kinds of a type variable. I have no idea | why this was there, other than as a holdover from pre-TypeInType. | I've not left a Note because there is simply no reason I can | conceive | of that the FM_SubstOnly should be there. | | One challenge with this patch is that the emitted derived | equalities | might get emitted several times: when a heterogeneous equality is | in an implication and then gets floated out from the implication, | the Derived is present both in and out of the implication. This | causes a duplicate error message. (Test case: | typecheck/should_fail/T7368) Solution: track the provenance of | Derived constraints and refuse to float out a constraint that has | an insoluble Derived. | | Lastly, this labels one test (dependent/should_fail/RAE_T32a) | as expect_broken, because the problem is really #12919. The | different handling of constraints in this patch exposes the error. | | This fixes bugs #11198, #12373, #13530, and #13610. | | test cases: | typecheck/should_fail/{T8262,T8603,tcail122,T12373,T13530,T13610} | | | >--------------------------------------------------------------- | | 8e15e3d370e9c253ae0dbb330e25b72cb00cdb76 | compiler/typecheck/TcCanonical.hs | 296 | ++++++++++++--------- | compiler/typecheck/TcErrors.hs | 75 ++++-- | compiler/typecheck/TcEvidence.hs | 8 +- | compiler/typecheck/TcFlatten.hs | 31 ++- | compiler/typecheck/TcRnTypes.hs | 30 ++- | compiler/typecheck/TcSimplify.hs | 34 ++- | compiler/typecheck/TcType.hs | 10 +- | compiler/typecheck/TcUnify.hs | 28 +- | compiler/types/Type.hs | 4 +- | testsuite/tests/dependent/should_fail/T11471.hs | 2 +- | .../tests/dependent/should_fail/T11471.stderr | 11 +- | testsuite/tests/dependent/should_fail/all.T | 2 +- | testsuite/tests/gadt/gadt7.stderr | 6 +- | .../tests/ghci.debugger/scripts/break012.stdout | 14 +- | .../indexed-types/should_fail/ExtraTcsUntch.stderr | 6 +- | .../tests/indexed-types/should_fail/T5934.stderr | 13 - | testsuite/tests/polykinds/T12593.stderr | 56 ++++ | testsuite/tests/polykinds/T13555.stderr | 21 +- | testsuite/tests/polykinds/T7438.stderr | 6 +- | testsuite/tests/polykinds/T8566.stderr | 2 +- | testsuite/tests/polykinds/T9017.stderr | 10 +- | testsuite/tests/typecheck/should_fail/T12373.hs | 10 + | .../tests/typecheck/should_fail/T12373.stderr | 8 + | testsuite/tests/typecheck/should_fail/T13530.hs | 11 + | .../tests/typecheck/should_fail/T13530.stderr | 7 + | testsuite/tests/typecheck/should_fail/T13610.hs | 11 + | .../tests/typecheck/should_fail/T13610.stderr | 14 + | testsuite/tests/typecheck/should_fail/T5691.stderr | 10 +- | testsuite/tests/typecheck/should_fail/T7368.stderr | 6 +- | .../tests/typecheck/should_fail/T7368a.stderr | 2 +- | testsuite/tests/typecheck/should_fail/T7453.stderr | 48 +--- | testsuite/tests/typecheck/should_fail/T7696.stderr | 4 +- | testsuite/tests/typecheck/should_fail/T8262.stderr | 6 +- | testsuite/tests/typecheck/should_fail/T8603.hs | 4 + | testsuite/tests/typecheck/should_fail/T8603.stderr | 13 +- | testsuite/tests/typecheck/should_fail/all.T | 3 + | .../tests/typecheck/should_fail/tcfail090.stderr | 4 +- | .../tests/typecheck/should_fail/tcfail122.stderr | 8 +- | .../tests/typecheck/should_fail/tcfail123.stderr | 13 +- | .../tests/typecheck/should_fail/tcfail200.stderr | 6 +- | 40 files changed, 537 insertions(+), 316 deletions(-) | | Diff suppressed because of size. To see it, use: | | git diff-tree --root --patch-with-stat --no-color --find-copies- | harder --ignore-space-at-eol --cc | 8e15e3d370e9c253ae0dbb330e25b72cb00cdb76 | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h | askell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | commits&data=02%7C01%7Csimonpj%40microsoft.com%7C9993301a429e467e29b00 | 8d4d4e6350f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6363675325842 | 62688&sdata=JkrPJNfzdjx2Rz%2FfcMq2HlIP%2BlsFIE%2FT68a%2FSUae%2Fzo%3D&r | eserved=0

2 1

Reinstallable lib:ghc (was: [core libraries] Upgradeable base (smallest step forward))
by Herbert Valerio Riedel 27 Jul '17

27 Jul '17

Hi everyone, As part of the recent GHC 8.2.1 release and the associated boot-library publishing to Hackage, I picked up again experimenting with a reinstallable lib:ghc package primarily for the benefit of uploading haddocks for lib:ghc (w/ `--hyperlinked-source`) to Hackage: http://hackage.haskell.org/package/ghc However, this also provides somewhat of a tech-preview of a reinstallable lib:ghc package, which would help mitigate a big issue we had in the past with lib:ghc and its dependencies being frozen to specific versions, and which in combination with cabal's nix-style pkg store that finally provide us with the ability to have multiple instances of the same library versions co-existing in the same package db, is no longer a requirement. So we could have lib:ghc more easily pick dependencies up (but still within reason!) like e.g. lib:text without forcing everyone to the single lib:text version bundled with GHC. And we'd also gain the ability to publish patch-level releases to lib:ghc only inbetween proper minor GHC releases (e.g. to support new versions of library dependencies). Consider this artificial example demo package which requires a different version of binary than the one bundled with GHC 8.2.1: --8<---------------cut here---------------start------------->8--- -- ghc-demo.cabal name: ghc-demo version: 0 build-type: Simple cabal-version: >=2.0 executable ghc-demo main-is: Main.hs build-depends: base ^>= 4.10, ghc ^>= 8.2.1, binary == 0.8.5.0 default-language: Haskell2010 --8<---------------cut here---------------end--------------->8--- Trying to build this will have the cabal solver complain that the installed instance of ghc requires a different (& installed) version of binary, i.e. binary-0.8.5.1. Moreover, the source version of lib:ghc on Hackage has the manual `buildable` cabal flag which defaults to false, and currently prevents lib:ghc to be reinstalled automatically (by enabling an unsatisfiable constraint): --8<---------------cut here---------------start------------->8--- Resolving dependencies... cabal: Could not resolve dependencies: trying: base-4.10.0.0/installed-4.1... (dependency of ghc-demo-0) next goal: ghc (dependency of ghc-demo-0) rejecting: ghc-8.2.1/installed-8.2... (conflict: binary==0.8.5.0, ghc => binary==0.8.5.1/installed-0.8...) trying: ghc-8.2.1 rejecting: ghc-8.2.1:-buildable (conflict: base==4.10.0.0/installed-4.1..., ghc -buildable => base<0) rejecting: ghc-8.2.1:+buildable (manual flag can only be changed explicitly) After searching the rest of the dependency tree exhaustively, these were the goals I've had most trouble fulfilling: ghc-demo, binary, base, ghc, ghc-8.2.1:buildable --8<---------------cut here---------------end--------------->8--- However, if we unlock this by toggling the flag (NB: this only works on linux/x86_64; it's explained later why), e.g. --8<---------------cut here---------------start------------->8--- -- cabal.project file packages: . package ghc flags: +buildable --8<---------------cut here---------------end--------------->8--- The cabal solver would come up with an install-plan: --8<---------------cut here---------------start------------->8--- Resolving dependencies... Build profile: -w ghc-8.2.1 -O1 In order, the following will be built (use -v for more details): - binary-0.8.5.0 {binary-0.8.5.0-7f686cf5c40c3c685540306709c4a2a30d740679f5d31ad196283d242a4d70ac} (lib) (requires download & build) - ghc-boot-8.2.1 {ghc-boot-8.2.1-7930c3d78690c5fa476415d38abbb7717b05cf65e80cc79c12e782c9886507cb} (lib) (requires build) - ghci-8.2.1 {ghci-8.2.1-6292924619a045fd18e9fde0cfa350632672ad7439cb84a5c56ff0e4781346b1} (lib) (requires build) - ghc-8.2.1 {ghc-8.2.1-bc10931b0f169622deb74d84cf10e315730dfd8f2edcf4cad9073d142cf5da0c} (lib) +buildable (requires build) - ghc-demo-0 {ghc-demo-0-inplace-ghc-demo} (exe:ghc-demo) (first run) Configuring binary-0.8.5.0-7f686cf5c40c3c685540306709c4a2a30d740679f5d31ad196283d242a4d70ac (lib) Building binary-0.8.5.0-7f686cf5c40c3c685540306709c4a2a30d740679f5d31ad196283d242a4d70ac (lib) Installing binary-0.8.5.0-7f686cf5c40c3c685540306709c4a2a30d740679f5d31ad196283d242a4d70ac (lib) Finished binary-0.8.5.0-7f686cf5c40c3c685540306709c4a2a30d740679f5d31ad196283d242a4d70ac (lib) Configuring ghc-boot-8.2.1-7930c3d78690c5fa476415d38abbb7717b05cf65e80cc79c12e782c9886507cb (lib) Building ghc-boot-8.2.1-7930c3d78690c5fa476415d38abbb7717b05cf65e80cc79c12e782c9886507cb (lib) Installing ghc-boot-8.2.1-7930c3d78690c5fa476415d38abbb7717b05cf65e80cc79c12e782c9886507cb (lib) Finished ghc-boot-8.2.1-7930c3d78690c5fa476415d38abbb7717b05cf65e80cc79c12e782c9886507cb (lib) Configuring ghci-8.2.1-6292924619a045fd18e9fde0cfa350632672ad7439cb84a5c56ff0e4781346b1 (lib) Building ghci-8.2.1-6292924619a045fd18e9fde0cfa350632672ad7439cb84a5c56ff0e4781346b1 (lib) Installing ghci-8.2.1-6292924619a045fd18e9fde0cfa350632672ad7439cb84a5c56ff0e4781346b1 (lib) Finished ghci-8.2.1-6292924619a045fd18e9fde0cfa350632672ad7439cb84a5c56ff0e4781346b1 (lib) Configuring ghc-8.2.1-bc10931b0f169622deb74d84cf10e315730dfd8f2edcf4cad9073d142cf5da0c (lib) Building ghc-8.2.1-bc10931b0f169622deb74d84cf10e315730dfd8f2edcf4cad9073d142cf5da0c (lib) Installing ghc-8.2.1-bc10931b0f169622deb74d84cf10e315730dfd8f2edcf4cad9073d142cf5da0c (lib) Finished ghc-8.2.1-bc10931b0f169622deb74d84cf10e315730dfd8f2edcf4cad9073d142cf5da0c (lib) Configuring executable 'ghc-demo' for ghc-demo-0.. Preprocessing executable 'ghc-demo' for ghc-demo-0.. Building executable 'ghc-demo' for ghc-demo-0.. [1 of 1] Compiling Main ( Main.hs, /tmp/lll/dist-newstyle/build/x86_64-linux/ghc-8.2.1/ghc-demo-0/c/ghc-demo/build/ghc-demo/ghc-demo-tmp/Main.o ) Linking /tmp/lll/dist-newstyle/build/x86_64-linux/ghc-8.2.1/ghc-demo-0/c/ghc-demo/build/ghc-demo/ghc-demo ... --8<---------------cut here---------------end--------------->8--- So, cabal was able to succesfully produce an executable which uses a reinstalled lib:ghc w/ a different lib:binary version! But now for the limitations: this currently works at best with a GHC 8.2.1 installation whose configuration matches the generated files I manually included in the modified lib:ghc package in http://hackage.haskell.org/package/ghc-8.2.1/src/autogen/ which as you can see from the generated files (see e.g. Config.hs) was a Linux/x86_64/libgmp/internal-libffi/... configuration. ...and this finally brings me to the purpose of why I wrote this email: In order to make lib:ghc properly reinstallable we'd need to either a) have a way to regenerate the files autogen/* via a custom Setup.hs (by the likes of genprimcode or similiar) or the lazy option, b) simply have those files installed in a place we can easily locate (again, from a custom Setup.hs) Does this make any sense; which option do you prefer? Also, I'd like to know if you can think of reasons why or situations when the reinstalled lib:ghc wouldn't work; or other reasons why this is a bad idea. Cheers, hvr On 2016-06-05 at 19:02:29 +0200, Herbert Valerio Riedel wrote: >> As an ultimate goal for a project like this, it would be nice if you could >> do something like upgrade your base package but continue to use the ghc >> package without incompatible types. > > That's one way to approach this. However, I've been experimenting with a > more flexible way: Thanks to cabal-1.24's new nix-based tech-preview > which gets rid of that `--force-reinstall` abomination for good, the > prospect of simply recompiling the `ghc` cabal package becomes more > attractive. > > This would get rid of the primary reason which currently constraints us > to using the package versions bundled in GHC (like e.g. for > `bytestring`) as soon as `ghc` enters an install-plan. > > I'm still investigating this, but early experiments were promising, but > I need to reorganise GHC's source-tree a little bit to know for sure if > this is feasable. But if this as I hope is possible, this could open up > a lot of new possibilities!

3 2

Frontend Plugins Proposal
by Matthew Pickering 25 Jul '17

25 Jul '17

4 years ago Edsko proposed a patch to add support for frontend plugins to GHC. You can read his proposal here - https://ghc.haskell.org/trac/ghc/wiki/FrontendPluginsProposal#no1 Something like core to core plugins but for typechecked code would be useful for tool writers. Does anyone know why the patch was never merged? Confusingly Edward Yang implemented another feature called frontend plugins which does something quite different (allowing users to write custom major modes rather than hook into the frontend). These features are quite different to each other. Thanks, Matt

2 1

RE: D3754: Refactor uo_thing
by Simon Peyton Jones 24 Jul '17

24 Jul '17

Richard I'm on a train, so can't look at the detail. But the following thought occurs to me. uo_thing is a Maybe SDoc attached to a constraint. But a constraint also has a stack of [ErrCtxt], captured in the CtLoc. That's what produces the "In the declaration for ..." stuff. Idea: instead of uo_thing, could we just push an extra ErrCtxt onto the stack, in the CtLoc for this constraint? (Or not, in the Nothing case.) Simon From: noreply(a)phabricator.haskell.org [mailto:noreply@phabricator.haskell.org] Sent: 18 July 2017 19:39 To: Simon Peyton Jones <simonpj(a)microsoft.com> Subject: [Differential] [Request, 533 lines] D3754: Refactor uo_thing goldfire created this revision. Herald added subscribers: thomie, rwbarton. Herald added a reviewer: hvr. View Revision<https://phabricator.haskell.org/D3754> REVISION SUMMARY The uo_thing field of TypeEqOrigin is used to track the "thing" (either term or type) that has the type (kind) stored in the TypeEqOrigin fields. Previously, this was sometimes a proper Core Type, which needed zonking and tidying. Now, it is only HsSyn: much simpler, and the error messages now use the user-written syntax. But this aspect of uo_thing didn't cause Trac #13819<https://ghc.haskell.org/trac/ghc/ticket/13819>; it was the sibling field uo_arity that did. uo_arity stored the number of arguments of uo_thing, useful when reporting something like "should have written 2 fewer arguments". We wouldn't want to say that if the thing didn't have two arguments. However, in practice, GHC was getting this wrong, and this message didn't seem all that helpful. Furthermore, the calculation of the number of arguments is what caused Trac #13819<https://ghc.haskell.org/trac/ghc/ticket/13819> to fall over. This patch just removes uo_arity. In my opinion, the change to error messages is a nudge in the right direction. Test case: typecheck/should_fail/T13819 TEST PLAN ./validate REPOSITORY rGHC Glasgow Haskell Compiler BRANCH wip/rae REVISION DETAIL https://phabricator.haskell.org/D3754 AFFECTED FILES compiler/ghci/RtClosureInspect.hs compiler/typecheck/Inst.hs compiler/typecheck/TcArrows.hs compiler/typecheck/TcErrors.hs compiler/typecheck/TcExpr.hs compiler/typecheck/TcHsType.hs compiler/typecheck/TcMType.hs compiler/typecheck/TcPat.hs compiler/typecheck/TcRnTypes.hs compiler/typecheck/TcSigs.hs compiler/typecheck/TcSplice.hs compiler/typecheck/TcSplice.hs-boot compiler/typecheck/TcTyClsDecls.hs compiler/typecheck/TcType.hs compiler/typecheck/TcUnify.hs compiler/typecheck/TcUnify.hs-boot compiler/types/Type.hs testsuite/tests/indexed-types/should_fail/T12867.stderr testsuite/tests/polykinds/T12593.stderr testsuite/tests/polykinds/T6039.stderr testsuite/tests/polykinds/T7278.stderr testsuite/tests/polykinds/T8616.stderr testsuite/tests/polykinds/T9200b.stderr testsuite/tests/rename/should_fail/rnfail026.stderr testsuite/tests/th/T3177a.stderr testsuite/tests/typecheck/should_fail/T11356.stderr testsuite/tests/typecheck/should_fail/T11672.stderr testsuite/tests/typecheck/should_fail/T12785b.stderr testsuite/tests/typecheck/should_fail/T13819.hs testsuite/tests/typecheck/should_fail/T13819.stderr testsuite/tests/typecheck/should_fail/T2994.stderr testsuite/tests/typecheck/should_fail/T3540.stderr testsuite/tests/typecheck/should_fail/T4875.stderr testsuite/tests/typecheck/should_fail/T7609.stderr testsuite/tests/typecheck/should_fail/T7778.stderr testsuite/tests/typecheck/should_fail/all.T testsuite/tests/typecheck/should_fail/tcfail070.stderr testsuite/tests/typecheck/should_fail/tcfail078.stderr testsuite/tests/typecheck/should_fail/tcfail113.stderr testsuite/tests/typecheck/should_fail/tcfail123.stderr testsuite/tests/typecheck/should_fail/tcfail132.stderr EMAIL PREFERENCES https://phabricator.haskell.org/settings/panel/emailpreferences/ To: goldfire, simonpj, austin, bgamari, hvr Cc: rwbarton, thomie, Mikolaj, fryguybob, carter, mpickering, adamgundry

2 1

Re: [GHC] #14005: Explore moving from pretty to prettyprinter
by Siddharth Bhat 22 Jul '17

22 Jul '17

Ben, Thank you for the fix :) However, the link appears to be broken? On Sat, 22 Jul 2017 at 23:15 GHC <ghc-devs(a)haskell.org> wrote: > #14005: Explore moving from pretty to prettyprinter > -------------------------------------+------------------------------------- > Reporter: bgamari | Owner: (none) > Type: task | Status: new > Priority: normal | Milestone: 8.4.1 > Component: Compiler | Version: 8.0.1 > Resolution: | Keywords: > Operating System: Unknown/Multiple | Architecture: > | Unknown/Multiple > Type of failure: None/Unknown | Test Case: > Blocked By: | Blocking: > Related Tickets: | Differential Rev(s): Phab:D3650 > Wiki Page: | > wiki:PrettyErrors | > -------------------------------------+------------------------------------- > > Comment (by bgamari): > > For the record, my > [[ > https://github.com/bgamari/ghc/commit/5256c89d3172d353d4ebc595b8c38c7ae5a79… > ]] > contains a rather hacky fix for this in issue (at least in the case of the > NCG). > > -- > Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14005#comment:8> > GHC <http://www.haskell.org/ghc/> > The Glasgow Haskell Compiler > -- Sending this from my phone, please excuse any typos!

1 0

Repeated computations under a lambda
by Conal Elliott 19 Jul '17

19 Jul '17

I'm seeing what looks like repeated computation under a lambda with `-O` and `-O2`. The following definition: > exampleC :: Double -> Double -> Double > exampleC = \ t -> let s = sin t in \ x -> x + s yields this Core: > -- RHS size: {terms: 13, types: 6, coercions: 0} > exampleC :: Double -> Double -> Double > exampleC = > \ (t_afI6 :: Double) (eta_B1 :: Double) -> > case eta_B1 of _ { D# x_aj5c -> > case t_afI6 of _ { D# x1_aj5l -> > D# (+## x_aj5c (sinDouble# x1_aj5l)) > } > } The `sinDouble#` here depends only on `t_afI6` (`t`) but still appears under the binding of `eta_B1` (`x`). I'm concerned because many of my uses of such functions involve computations dependent only on `t` (time) but with millions of uses (space) per `t`. (I'm working on a GHC Core plugin (compiling to categories), with one use generating graphics GPU code.) Does the optimization I expected somehow happen later in the compilation pipeline? Are there Core-manipulating functions in GHC that I can use to make it happen earlier (via a `BuiltinRule`, i.e., Core-to-Core function)? Thanks, -- Conal

5 11

Proposed: Language.Haskell.TH.Internal
by Richard Eisenberg 18 Jul '17

18 Jul '17

Hi devs, This is a brief proposal for an internal, non-user-facing restructuring of the implementation of Template Haskell. It's here (instead of at ghc-proposals) because it's not user-facing. When a user writes a TH quote [| foo bar baz |], GHC must desugar that into some Core code that builds a Q Exp. This is currently done by calling functions in Language.Haskell.TH.Lib, which is capable of building all the TH abstract syntax. However, many end-users of TH *also* import Language.Haskell.TH.Lib and use its functions. This means that, as the Haskell AST evolves, we can't reasonably evolve this Lib module, as it breaks user code. (There is a requisite amount of churn in TH, but we try to avoid gratuitous changes in Lib.) This has bitten in the past when we have, say, changed the representation of type families to accommodate closed type families, and it's biting now as we (ahem, Ryan Scott) are trying to merge types and kinds in TH. I thus propose a new module Language.Haskell.TH.Internal. This will start out as a slimmed-down copy of Lib (slimmed-down because Lib already has a bunch of now-disused functions) but may evolve independently. Desugaring quotes will go via this new Internal module, and we will have no qualms about changing its interface, as it's Internal. What do we think? Ryan has already implemented this idea in D3751. Pros: - Flexibility - Separation between user-facing interface and internal interface Cons: - More stuff - We already break the TH API with every release; maybe it's not so bad to break more of it. Thanks, Richard

3 2