December 2016 - ghc-devs

Default options for -threaded
by lonetiger＠gmail.com 04 Jan '19

04 Jan '19

Hi All, A user on https://ghc.haskell.org/trac/ghc/ticket/11054 has asked why -N -qa isn’t the default for -threaded. I’m afraid I don’t know a good reason why it’s not. Can anyone help shed some light on this? If there is no good reason, Would anyone object to making it the default? Thanks, Tamar

7 10

Cross-compiling Template Haskell via -fexternal-interpreter and IPC
by Alberto Valverde 30 May '17

30 May '17

Hello, I'm trying to put together a GHC 8.0.1 cross-compiler with Template Haskell support. Initially to target Windows (32bits) from a Linux host but a similar procedure should enable to target other platforms too. I'd like to contribute the patches back so I'm asking for advice on how to implement it in order to increase the chances of them being accepted. I've managed to get a working stage 1 cross-compiler with some patches which correctly builds all stage1 libs and GHC + stage 2 compiler and ghc-iserv.exe. However, compiling TH by using wine and ghc-iserver.exe fails because the file descriptor ids that GHC passes as arguments to "wine ghc-iserv.exe" don't make sense in the emulated windows world. I've hacked around this to test the feasibility of the approach by using stdin/stdout instead of creating new pipes and, surprisingly, managed to cross-compile a simple Template Haskell program. I'm considering using a socket for communicating between both processes as a more permanent solution but this would incur in a dependency on the "network" package. Would this be acceptable? Named pipes have also crossed my mind but I'm not sure how well they're supported by wine. Thanks for your attention. Alberto P.S: Code is in the "cross-mingw-hacks" branches of these repositories and is based on the ghc-8.0.1-release tag: https://github.com/albertov/ghc https://github.com/albertov/hsc2hs A Docker image script here that builds it is here: https://github.com/albertov/ghc-cross-compiler-windows-x86

6 11

GHC 8.0.1-rc4 source tarball availability
by Ben Gamari 14 May '17

14 May '17

tl;dr: If you would like to produce a binary distribution for GHC 8.0.1-rc4 then let us know, grab the source distribution and start building. The binary distributions will be all released one week from today. Hello GHC packagers, I am happy to announce the release of the 8.0.1-rc4 source distribution to binary packagers. This release should resolve all of the issues noted in the release candidate 3 announcement. You will find the usual artifacts at http://downloads.haskell.org/~ghc/8.0.1-rc4/ For this candidate we are again following our new release policy [1], with a one-week delay between the release of the source and binary distributions. The goal of this policy is to give all platforms the opportunity for support from the first day of a release. If all of the expected binary releases are submitted before the week-long delay has elapsed, we will move forward with the release of the binaries on an accelerated schedule. It would be appreciated if you could reply to this message confirming that you intend to offer a binary distribution this release. Otherwise, let either Austin or I know if you have any trouble building your distribution. I have yet to push the ghc-8.0.1-rc4 tag in case we encounter unexpected issues but all of my builds with this tarball thusfar have gone quite well. Good luck and thanks for all of your work! Cheers, - Ben [1] https://mail.haskell.org/pipermail/ghc-devs/2016-March/011546.html

12 75

Improving trac notifications
by Matthew Pickering 12 Feb '17

12 Feb '17

I subscribe to the ghc-tickets[1] mailing list which provides updates to all trac tickets. This is very useful, however when a ticket description is updated the whole description is included in the email which makes it hard to see what actually changed. The web interface shows a nice diff[2] of the changes, I think it would be good if emails could also include a diff rather than the current quite useless output. After a bit of investigation, it appears that the easiest way to achieve this is apply a simple patch to our copy of trac. The current format is hard coded on line 558 in this module, it seems easy to modify this section to instead provide a diff. http://www.edgewall.org/docs/trac-trunk/epydoc/trac.ticket.notification-pys… There is also already a module which has the diff operations implemented which could be used. http://www.edgewall.org/docs/trac-trunk/epydoc/trac.versioncontrol.diff-mod… Another option would be to use something like the `AnnouncerPlugin`[3] but that seems like much more work and would still require someone to write a custom formatter. Any thoughts? Matt [1]: https://mail.haskell.org/mailman/listinfo/ghc-tickets [2]: https://ghc.haskell.org/trac/ghc/ticket/10873?action=diff&version=6 [3]: https://trac-hacks.org/wiki/AnnouncerPlugin

3 8

simple pictures about GHC development flow
by Takenobu Tani 28 Jan '17

28 Jan '17

Hi devs, For myself and new contributors, I drew overview pictures about GHC development flow. GHC development flow http://takenobu-hs.github.io/downloads/ghc_development_flow.pdf https://github.com/takenobu-hs/ghc-development-flow If I misunderstood something, please teach me. I'll correct or remove them. Regards, Takenobu

4 15

Magical function to support reflection
by David Feuer 20 Jan '17

20 Jan '17

The following proposal (with fancier formatting and some improved wording) can be viewed at https://ghc.haskell.org/trac/ghc/wiki/MagicalReflectionSupport Using the Data.Reflection has some runtime costs. Notably, there can be no inlining or unboxing of reified values. I think it would be nice to add a GHC special to support it. I'll get right to the point of what I want, and then give a bit of background about why. === What I want I propose the following absurdly over-general lie: reify# :: (forall s . c s a => t s r) -> a -> r `c` is assumed to be a single-method class with no superclasses whose dictionary representation is exactly the same as the representation of `a`, and `t s r` is assumed to be a newtype wrapper around `r`. In desugaring, reify# f would be compiled to f@S, where S is a fresh type. I believe it's necessary to use a fresh type to prevent specialization from mixing up different reified values. === Background Let me set up a few pieces. These pieces are slightly modified from what the package actually does to make things cleaner under the hood, but the differences are fairly shallow. newtype Tagged s a = Tagged { unTagged :: a } unproxy :: (Proxy s -> a) -> Tagged s a unproxy f = Tagged (f Proxy) class Reifies s a | s -> a where reflect' :: Tagged s a -- For convenience reflect :: forall s a proxy . Reifies s a => proxy s -> a reflect _ = unTagged (reflect' :: Tagged s a) -- The key function--see below regarding implementation reify' :: (forall s . Reifies s a => Tagged s r) -> a -> r -- For convenience reify :: a -> (forall s . Reifies s a => Proxy s -> r) -> r reify a f = reify' (unproxy f) a The key idea of reify' is that something of type forall s . Reifies s a => Tagged s r is represented in memory exactly the same as a function of type a -> r So we can currently use unsafeCoerce to interpret one as the other. Following the general approach of the library, we can do this as such: newtype Magic a r = Magic (forall s . Reifies s a => Tagged s r) reify' :: (forall s . Reifies s a => Tagged s r) -> a -> r reify' f = unsafeCoerce (Magic f) This certainly works. The trouble is that any knowledge about what is reflected is totally lost. For instance, if I write reify 12 $ \p -> reflect p + 3 then GHC will not see, at compile time, that the result is 15. If I write reify (+1) $ \p -> reflect p x then GHC will never inline the application of (+1). Etc. I'd like to replace reify' with reify# to avoid this problem. Thanks, David Feuer

6 16

[GHC Proposal] "Constraint to Bool" wired-in type family
by Ben Gamari 17 Jan '17

17 Jan '17

Hello everyone, Sylvain Henry just opened Pull Request #22 [1] against the ghc-proposals repository. This proposal describes a type family which would given users access to type-level evidence of the satisfiability of a constraint. Please feel free to read and discuss the proposal on the pull request. Cheers, - Ben [1] https://github.com/ghc-proposals/ghc-proposals/pull/22

1 1

Exhaustiveness checking for pattern synonyms
by Matthew Pickering 14 Jan '17

14 Jan '17

Hello devs, I have implemented exhaustiveness checking for pattern synonyms. The idea is very simple, you specify a set of pattern synonyms (or data constructors) which are regarded as a complete match. The pattern match checker then uses this information in order to check whether a function covers all possibilities. Specification: https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms/CompleteSigs https://phabricator.haskell.org/D2669 https://phabricator.haskell.org/D2725 Matt

3 4

Inlining Wiki Page
by Matthew Pickering 12 Jan '17

12 Jan '17

Dear Devs, I've spent the last day looking at the inliner. In doing so I updated the wiki page about inlining to be a lot more useful to other people wanting to understand the intricacies and problems. https://ghc.haskell.org/trac/ghc/wiki/Inlining This looks like the perfect place for a newcomer to start working on GHC. The inliner is quite well contained, there are lots of open tickets with well-specified aims and lots of investigatory work to be done. So the purpose of this email is: 1. Please tag any tickets relevant to inlining/specialisation with "Inlining" 2. Any newcomers keen to get involved should read the wiki page and see if they can tackle one of the tickets there. Matt

3 3

many haskell's mails are detected as spam on gmail
by Takenobu Tani 12 Jan '17

12 Jan '17

Hi, I'm using gmail. Recently, many haskell's mails are detected as spam on gmail. (ghc-devs, haskell-cafe, ghc-commit, ...) Does anyone know why? Do you know the workaround? Regards, Takenobu

5 4