- ghc-devs - Haskell.org

Open up the issues tracker on ghc-proposals
by David Feuer 01 May '18

01 May '18

Sometimes, a language extension idea could benefit from some community discussion before it's ready for a formal proposal. I'd like to propose that we open up the GitHub issues tracker for ghc-proposals to serve as a place to discuss pre-proposal ideas. Once those discussions converge on one or a few specific plans, someone can write a proper proposal.

4 5

Testsuite wobbles
by Simon Peyton Jones 01 May '18

01 May '18

Friends I'm seeing test-suite wobbles like these: Unexpected failures: /tmp/ghctest-9ez8i8lx/test spaces/./ghci.debugger/scripts/break006.run break006 [bad stdout] (ghci) /tmp/ghctest-9ez8i8lx/test spaces/./ghci.debugger/scripts/hist001.run hist001 [bad stdout] (ghci) /tmp/ghctest-9ez8i8lx/test spaces/./ghci.debugger/scripts/hist002.run hist002 [bad stdout] (ghci) /tmp/ghctest-9ez8i8lx/test spaces/./profiling/should_run/scc001.run scc001 [bad profile] (profasm) It turns out that they are all variations in the order of output, e.g. --- ./scripts/break006.run/break006.stdout.normalised 2018-05-01 13:20:13.297808002 +0100 +++ ./scripts/break006.run/break006.run.stdout.normalised 2018-05-01 13:20:13.297808002 +0100 @@ -4,14 +4,14 @@ x :: Integer = 1 xs :: [Integer] = [2,3] xs :: [Integer] = [2,3] -f :: Integer -> a = _ x :: Integer = 1 +f :: Integer -> a = _ _result :: [a] = _ y = (_t1::a) y = 2 xs :: [Integer] = [2,3] -f :: Integer -> Integer = _ x :: Integer = 1 +f :: Integer -> Integer = _ _result :: [Integer] = _ y :: Integer = 2 _t1 :: Integer = 2 *** unexpected failure for break006(ghci) I've seen this go to and fro recently. It looks as if the output is not deterministic somehow. (The order in which the bindings are printed is immaterial.) Does this happen for others? Does the master CI build show this problem? I don't know whether to commit these changes, because I don't know if it affects anyone else. And it's certainly tiresome for me. Any ideas? Simon

1 0

[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

Re: [GHC] #9476: Implement late lambda-lifting
by Nicolas Frisby 25 Apr '18

25 Apr '18

I'm happy this is seeing some attention! I've habitually over promised on this and feel bad about that. My work-life-hobby programming balance has remained a mystery to me. Even so, I'll give what answers I can to any questions that come up. I remember ultimately getting stuck on trying to identify a broadly useful heuristic: there are lots of possible parameters to tune and I was seeing massive run time differences for nofib cases on different CPU architectures for equivalent LLF parameters. I never managed to get a good handle on the crucial independent variables (e.g. code cache sizes, RTS parameters, etc). I'm hoping the join point work revealed some easier wins. Best of luck and don't hesitate to ping me with questions. Hope I can help. On Wed, Apr 25, 2018, 10:33 GHC <ghc-devs(a)haskell.org> wrote: > #9476: Implement late lambda-lifting > -------------------------------------+------------------------------------- > Reporter: simonpj | Owner: nfrisby > Type: feature request | Status: new > Priority: normal | Milestone: > Component: Compiler | Version: 7.8.2 > Resolution: | Keywords: > Operating System: Unknown/Multiple | Architecture: > Type of failure: Runtime | Unknown/Multiple > performance bug | Test Case: > Blocked By: | Blocking: > Related Tickets: #8763 | Differential Rev(s): > Wiki Page: LateLamLift | > -------------------------------------+------------------------------------- > > Comment (by simonpj): > > OK, great. Do keep us posted. I think there are real wins to be had > here. Nicholas's detailed wiki page identifies many of the issues very > clearly. > > -- > Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9476#comment:12> > GHC <http://www.haskell.org/ghc/> > The Glasgow Haskell Compiler >

1 0

RE: [core libraries] Re: Name for unary unboxed one-tuple
by Simon Peyton Jones 25 Apr '18

25 Apr '18

OK great, thanks. Solo# is it. Adding ghc-devs: would someone like to make a patch? Simon From: Edward Kmett <ekmett(a)gmail.com> Sent: 25 April 2018 17:13 To: Andrew Martin <andrew.thaddeus(a)gmail.com> Cc: Simon Peyton Jones <simonpj(a)microsoft.com>; core-libraries-committee(a)haskell.org; Haskell Libraries <libraries(a)haskell.org> Subject: Re: [core libraries] Re: Name for unary unboxed one-tuple Argh. Not another color for the bikeshed. We were so close to a nice universal consensus given your +1 on the thread. =) Let's end this and just go with Simon's Solo# as it had already achieved a reasonably wide consensus on the thread and we can put this to bed. Simon: I'd replied a couple of weeks ago on the trac ticket to try to end this, but apparently didn't visibly weigh in in a fashion that obviously carried the full force of the committee. -Edward On Wed, Apr 25, 2018 at 8:40 AM, Andrew Martin <andrew.thaddeus(a)gmail.com<mailto:andrew.thaddeus@gmail.com>> wrote: My vote is for Single/Single#. Also, in case there is any confusion around this, I was not a member of the CLC when this issue was originally raised, but the committee has accepted me since then. On Wed, Apr 25, 2018 at 4:28 AM, Simon Peyton Jones via Libraries <libraries(a)haskell.org<mailto:libraries@haskell.org>> wrote: Dear Libraries Committee Some time ago Andrew Martin asked you<https://mail.haskell.org/pipermail/libraries/2018-January/028419.html> what the name of the unary unboxed one-tuple type and data constructor should be. The thread ran for a while, but you never came to a conclusion. Can we nail this one? You’ll see on Trac #14673<https://ghc.haskell.org/trac/ghc/ticket/14673#comment:19> that chessai wants me to decide 😊. But it should really be you. To me, there seems to be something of a consensus around Solo#. Simon PS: actually I think Andrew may have addressed libraries@ rather than core-libraries-committee@ by mistake. _______________________________________________ Libraries mailing list Libraries(a)haskell.org<mailto:Libraries@haskell.org> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskel…> -- -Andrew Thaddeus Martin -- You received this message because you are subscribed to the Google Groups "haskell-core-libraries" group. To unsubscribe from this group and stop receiving emails from it, send an email to haskell-core-libraries%2Bunsubscribe(a)googlegroups.com<mailto:haskell-core-libraries+unsubscribe@googlegroups.com>. For more options, visit https://groups.google.com/d/optout<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.goo…>.

2 3

GHC HCAR submission
by Ben Gamari 25 Apr '18

25 Apr '18

tl;dr. Add your project to GHC's HCAR submission [1]. Hello everyone, I have uploaded a first draft of GHC's May 2018 HCAR submission to the Wiki [1]. While I believe I have covered most of the on-going projects, do check that your project appears and feel free to make any edits you feel appropriate. Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/wiki/Status/Apr18

2 1

In which format should GHC expose documentation via its .hi-files?
by Simon Jakobi 24 Apr '18

24 Apr '18

Hi! In preparation for the coding phase of the Hi Haddock proposal that I want to implement, I need a decision on the format in which we should expose haddocks in GHC's .hi interface files. Please visit https://github.com/haskell/haddock/issues/805, ask questions, make suggestions and help me find a timely decision! :) Cheers, Simon

1 0

Type family constraints
by Alan & Kim Zimmerman 23 Apr '18

23 Apr '18

Given data GhcPass (c :: Pass) deriving instance Eq (GhcPass c) deriving instance Typeable c => Data (GhcPass c) data Pass = Parsed | Renamed | Typechecked deriving (Data) Is there any way to express that `pass` must be valid for each value of `Pass` in the following instance head? instance (p ~ GhcPass pass, OutputableBndrId p) => Outputable (HsIPBinds p) where This comes from a problem where setting each type family instance separately does not get picked up during instance resolution (and can't be, according to earlier questions by me on this) i.e. type instance XIPBinds (GhcPass 'Parsed) = NoExt type instance XIPBinds (GhcPass 'Renamed) = NoExt type instance XIPBinds (GhcPass 'Typechecked) = TcEvBinds it works fine for type instance XIPBinds (GhcPass _) = NoExt Alan

3 3

RE: primitive library
by Simon Peyton Jones 23 Apr '18

23 Apr '18

This got longer than I thought it would. I'll work on something that talks more about motivations and features soon. That would be great, thanks. It would also mean that more people would use the new stuff, sooner. Simon From: Andrew Martin <andrew.thaddeus(a)gmail.com> Sent: 23 April 2018 14:20 To: Simon Peyton Jones <simonpj(a)microsoft.com> Cc: David Feuer <david(a)well-typed.com>; ghc-devs <ghc-devs(a)haskell.org>; Haskell Libraries <libraries(a)haskell.org> Subject: Re: primitive library I'll get something together soon that explains my motivations. The short summary is that the types in primitive unpack better that their counterparts in vector (meaning, they unpack into one machine word instead of three). I started using these types in internal data structures in libraries I would write (since I didn't need slicing), and then just started noticing stuff I thought it would be nice to add. David noticed that a bunch of the typeclass instances were broken. I'd been working on a library quickcheck-classes that I use to test instances at my work place. The primitive library was missing a test suite, so I used it to test all the instances to ensure that the fixes David had written were correct. In the process, I found more broken instances and fixed them. The life lesson here is that property testing is important. PrimArray is an interesting story. Both winterland1989 and I had independently written libraries that did the same exact thing: implement a typed interface to ByteArray that keeps track of the element type. This makes PrimArray much safer to work with than ByteArray. Eventually, winterland's initial PR to bring this to primitive stalled. It implemented several other features (some of which may still eventually get added), but it's scope was large enough that no maintainer was able to feel comfortable approving it. More recently, I took at stab at doing the same thing, but I only added PrimArray, and after a lot of feedback from David, Carter, and Ryan, it got merged in. This got longer than I thought it would. I'll work on something that talks more about motivations and features soon. On Mon, Apr 23, 2018 at 5:48 AM, Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: Andrew, David I’ve seen a lot of traffic about the primitive library, in which you two are playing a leading role. Clearly something interesting is going on, but I have not been paying enough attention to work out what. Maybe lots of unrelated things? Maybe a handful of closely related things? Would you consider putting out a summary (to libraries and ghc-devs) to give an overview of the main threads, and any driving motivations. Why has all this blown up now? Meanwhile, thank you for being so active. Simon -- -Andrew Thaddeus Martin

1 0