April 2018 - ghc-devs

GHC's module hierarchy
by Simon Peyton Jones 02 Oct '19

02 Oct '19

Dear ghc-devs hsyl20 proposes a radical overhaul of the module structure of GHC itself. He or she suggested it six months ago in https://ghc.haskell.org/trac/ghc/ticket/13009 and has now offered a monster patch https://phabricator.haskell.org/D3647 It's clearly the result of a lot of work, but I was the only one who responded on the original ticket, and it'll affect all of your lives in a very immediate way. So, would you like to * consider the idea * look at the actual re-mapping of modules hsyl20 proposals * express an opinion about whether to go ahead Probably the ticket, rather than Phab, is the best place to comment on the general idea. I'd like to thank hsyl20. GHC's rather flat module structure has grown incrementally over years. But still, there are pros and cons. Simon

2 1

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

perf.haskell.org functional again
by Joachim Breitner 30 Nov '18

30 Nov '18

Hi, after a system upgrade to avoid weird linker errors, and after some fixes in the nofib submodule, http://perf.haskell.org/ghc is running again. I am collecting instruction counts instead of runtime, because the latter was just too often varying too wildly. I hope this will yield less false alarms. I am also running nofib with mode=fast. This way, building GHC, running the testsuite and nofib takes a bit over one hour. I hope this can keep up with y'all's commits (when it took 2h it couldn't). Now nothing of the setup requires a quiet dedicated machine, so if there is a need, we could move these builds into the cloud or into some CI infrastructure - but no changes are immediately planned. Enjoy, Joachim

5 11

Scavenging SRTs in scavenge_one
by Ben Gamari 26 Jun '18

26 Jun '18

Hi Simon, I'm a bit confused by scavenge_one; namely it doesn't scavenge SRTs. It appears that it is primarily used for remembered set entries but it's not at all clear why this means that we can safely ignore SRTs (e.g. in the FUN and THUNK cases). Can you shed some light on this? Cheers, - Ben

3 10

Plan for GHC 8.6.1
by Ben Gamari 22 Jun '18

22 Jun '18

Hello fellow lazy purists, With GHC 8.4.2 out the door, it is time to begin looking forward to 8.6.1. In keeping with our six-month release schedule, this release will be targetted for early-September, with the stable branch being cut in mid-to-late June. Remarkably, this is only 6 weeks away. If you have patches that you would like to see in 8.6.1, please do put them up on Phabricator and the 8.6.1 status page [1] in the coming weeks to ensure that there is sufficient time for review. If you have a patch which you are concerned won't make the cut-off, do say something. Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.6.1

4 4

ZuriHac 2018 GHC DevOps track - Request for Contributions
by Niklas Hambüchen 05 Jun '18

05 Jun '18

Hi GHC devs, The ZuriHac 2018 conference will feature a GHC DevOps track (which Andreas and I are coordinating), that will be all about fostering contributions to GHC and learning to hack it. There will be a room or two allocated at Zurihac for this purpose. We hope to focus on roughly these topics: * How to build GHC from source * How to iterate on changes quickly * What's the development workflow, how do I get my patch merged? * How do specific parts of GHC work * Extending GHC's test suite * Improving automation, processes and release quality * Documenting the undocumented If we are successful, we will have more GHC contributers after ZuriHac than before. But we need your contributions to add content to the track! Specifically, we're looking for ZuriHac attendees who could (help) run a session in this track. Such as: * Giving a talk about one of the above or related topics * Hosting a hack session where participants of the track work together on the GHC code base towards a specific goal * Being around as a "GHC mentor" during open hack sessions, helping new GHC contributors out To give some examples, I could offer to give a talk on a recent effort to improve Ctrl+C and signal handling in the RTS, and I would like to run a hack session where we add performance regression tests based on CPU instruction counters. Please contact Andreas or me (on this list or privately) if you think you could help in any of these directions! If you're not sure, contact us anyway and tell us your idea! Best, Niklas and Andreas ZuriHac 2018 GHC DevOps track coordinators

4 8

End of Windows Vista support in GHC-8.6?
by Simon Jakobi 09 May '18

09 May '18

Hi! Given that Vista’s EOL was in April 2017 <https://support.microsoft.com/en-us/help/22882/windows-vista-end-of-support> i assume that there’s no intention to keep supporting it in GHC-8.6!? I’m asking because I intend to use a function <https://msdn.microsoft.com/en-us/library/windows/desktop/dd405488.aspx> that requires Windows 7 or newer for #13362 <https://ghc.haskell.org/trac/ghc/ticket/13362>. Ending Vista support would also allow us to remove some workarounds <https://github.com/ghc/ghc/search?utf8=%E2%9C%93&q=Vista> mostly in RTS. Best, Simon

5 10

Poly-kinded type family
by alice 01 May '18

01 May '18

Hello. I’m trying to make a type family with resolving it inside type checking classes, like CmpNat. Its type signature is «type family Cmp (a :: k1) (b :: k2) :: Ordering», so the function is poly kinded. But it seems unclear how to make its TyCon. I’ve tried to follow the CmpNat and CmpSymbol style, and also saw Any TyCon in TysWiredIn. So this is my attempt: typeCmpTyCon :: TyCon typeCmpTyCon = mkFamilyTyCon name (binders ++ (mkTemplateAnonTyConBinders [ input_kind1, input_kind2 ])) orderingKind Nothing (BuiltInSynFamTyCon ops) Nothing NotInjective where name = mkWiredInTyConName UserSyntax gHC_TYPELITS (fsLit "Cmp") typeCmpTyFamNameKey typeCmpTyCon ops = BuiltInSynFamily { sfMatchFam = matchFamCmpType , sfInteractTop = interactTopCmpType , sfInteractInert = \_ _ _ _ -> [] } binders@[kv1, kv2] = mkTemplateKindTyConBinders [ liftedTypeKind, liftedTypeKind ] input_kind1 = mkTyVarTy (binderVar kv1) input_kind2 = mkTyVarTy (binderVar kv2) ghci says this: :kind Cmp Cmp :: forall {k0} {k1}. k0 -> k1 -> Ordering But then I try to apply it to some values and get this exception: :kind! Cmp 4 5 <interactive>:1:15: error: • Expected kind ‘k0’, but ‘4’ has kind ‘Nat’ • In the first argument of ‘Cmp’, namely ‘4’ In the type ‘Cmp 4 5’ <interactive>:1:17: error: • Expected kind ‘k1’, but ‘5’ has kind ‘Nat’ • In the second argument of ‘Cmp’, namely ‘5’ In the type ‘Cmp 4 5’ Does anyone know where I made a mistake? Any help would be appreciated.

2 3

[ANNOUNCE] GHC 8.4.2 released
by Ben Gamari 01 May '18

01 May '18

Hello everyone, The GHC team is pleased to announce the availability of GHC 8.4.2. The source distribution, binary distributions, and documentation for this release are available at https://downloads.haskell.org/~ghc/8.4.2 This release is a bug-fix release, fixing numerous regressions and bugs present in GHC 8.4.1. These include: * A regression resulting in some uses of `Control.Exception.evaluate` to be inappropriately optimised away (see #13930) * A regression resulting in segmentation faults of programs compiled with profiling (#14705) * A bug causing runtime system panics while running programs with retainer profiling (#14947) * The configure scripts now accepts a `--disable-dtrace` option, again allowing GHC to be bootstrapped on FreeBSD (#15040) * The version number of the `base` package has been bumped to 4.11.1.0 to reflect the addition of the `GHC.IO.FixIOException` type. This interface was added in 8.4.1 but the version bump was missed due to an oversight. * Support for DWARF debug information has been significantly improved (#14894, #14779) A more thorough list of the changes in this release can be found in the release notes, https://downloads.haskell.org/~ghc/8.4.2/docs/html/users_guide/8.4.2-notes.… Thanks to everyone who has contributed to developing, documenting, and testing this release! 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

5 5

Discussion on proposal #99: forall {k}
by Iavor Diatchki 30 Apr '18

30 Apr '18

Hello, As a shepherd for proposal #99, I'd like to kick off the discussion. The full proposal is available here: https://github.com/goldfirere/ghc-proposals/blob/explicit-specificity/propo… Summary: allows programmers to write `forall {x}` instead of `forall x` in type signatures. The meaning of the braces is that this parameter cannot be instantiated with an explicit type application and will always be inferred. The motivation is to shorten explicit type applications by skipping parameters that are known to be inferable, the common example being omitting the kinds in signatures with poly kinds. As I understand it, the main motivation for this proposals is to give programmers more flexibility when instantiating type variables, with a less noisy syntax. While the proposed solution might work in some situations, I am unconvinced that it is the best way to address the issue in general, for the following reasons: 1. It requires that programmers commit at declaration time about which arguments will be inferred, and which may be inferred or specified. While in some cases this may be an easy decision to make, in many cases this really is a decision which should be made at the use site of a function (e.g., I'd like to provide argument X, but would like GHC to infer argument Y). 2. It still requires that programmers instantiate arguments in a fixed order, which is sometimes dictated by the structure of the type itslef. Here is, for example, what the proposal suggests to do if you want to provide type before a kind: typeRep4 :: forall {k} (a :: k) k'. (k ~ k', Typeable a) => TypeRep a While technically this is not wrong, it is not exactly elegant. I think that we should reject this proposal, and try to come up with a more comprehensive solution to the problem. One alternative design is to allow programmers to instantiate type variables by name. This is much more flexible as it allows programmers to instantiate whichever variables they want, and in whatever order. We've been doing this in Cryptol for a long time, and it seems to work really well. -Iavor

1 0