- ghc-devs - Haskell.org

Request for Nominations to the GHC Steering Committee
by Joachim Breitner 14 Jul '18

14 Jul '18

Dear Haskell community, the GHC Steering committee is seeking nominations for a new member. The committee scrutinizes, nitpicks, improves, weights and eventually accepts or rejects proposals that extend or change the language supported by GHC and other (public-facing) aspects of GHC. Our processes are described at https://github.com/ghc-proposals/ghc-proposals which is also the GitHub repository where proposals are proposed. We are looking for a member who has the ability * to understand such language extension proposals, * to find holes and missing corner cases in the specifications, * foresee the interaction with other language features and specifications, * comment constructively and improve the proposals, * judge the cost/benefit ratio and * finally come to a justifiable conclusion. We look for committee members who have some of these properties: * have substantial experience in writing Haskell applications or libraries, which they can use to inform judgements about the utility or otherwise of proposed features, * have made active contributions to the Haskell community, for some time, * have expertise in language design and implementation, in either Haskell or related languages, which they can share with us. The committee’s work requires a small, but non-trivial amount of time, especially when you are assigned a proposal for shepherding. We estimate the workload to be around 2 hours per week, and our process works best if members usually respond to technical emails within 1-2 weeks (within days is even better). Please keep that in mind if your email inbox is already overflowing. The GHC developers themselves are already well represented already. We seek Haskell _users_ more than GHC hackers. There is no shortage of people who are very eager to get fancy new features into the language, both in the committee and the wider community. But each new feature imposes a cost, to implement, to learn, (particularly) through its unexpected interaction with other features. We need to strike a balance, one that encourages innovation (as GHC always has) while still making Haskell attractive for real-world production use and for teaching. We therefore explicitly invite “conservative” members of the community to join the committee. To make a nomination, please send an email to me (as the committee secretary) at mail(a)joachim-breitner.de until July 23th. I will distribute the nominations among the committee, and we will keep the nominations and our deliberations private. We explicitly encourage self-nominations. You can nominate others, but please obtain their explicit consent to do so. (We don’t want to choose someone who turns out to be unable to serve.) On behalf of the committee, Joachim Breitner -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

RE:: Can a TC plugin create new skolem vars when simplifying Givens?
by Simon Peyton Jones 11 Jul '18

11 Jul '18

Nick writes Here's a small indicative example. In the "simplify Givens" step, the plugin receives [G] (p `Union` Singleton A) ~ (q `Union` Singleton B) and I would ideally simplify that to [G] p ~ (x `Union` Singleton B) [G] q ~ (x `Union` Singleton A) If we think of Union as a type-level function (which it is?), then the step you outline above is similar to what happens during “flattening” of the Givens. We get this: [G] fsk1 ~ p `Union` Singleton B (CFunEqCan) [G] fsk2 ~ q `Union` Singleton A (CFunEqCan) [G] fsk1 ~ fsk2 (CTyEqCan) * The newly generated skolems are called “flatten-skolems” or fsks for short. * The new skolems are kept in the `inert_fsks` field of the `InertSet`. * A new one is created by `TcSMonad.newFlattenSkolem` * All fsks are eliminated by TsSMonad.unflattenGivens Returning to your point, you are exploiting a property of sets that allows you to say that if p U X = q U Y Then suppose r = p • q then p = r U Y, q = r U X And now we can eliminate all uses of p, q in favour of r. But if you do this in a type system, we have a problem: where is ‘r’ bound? E.g. if you have f :: forall p q. (p `Union` A) ~ (q `Union` B) => blah Then p, q are bound by the forall, but r is not. To put it another way, what well-typed Core program would you like to generate? You could do this: [G] fsk1 ~ p `Union` Singleton B (CFunEqCan) [G] fsk2 ~ q `Union` Singleton A (CFunEqCan) [G] fsk3 ~ p `Intersect` q (CFunEqCan) [G] fsk4 ~ fsk3 `Union` Singleton B (CFunEqCan) [G] fsk5 ~ fsk3 `Union` Singleton A (CFunEqCan) [G] fsk1 ~ fsk2 (CTyEqCan) [G] p ~ fks4 (CTyEqCan) [G] q ~ fsk5 (CTyEqCan) The ‘r’ is just fsk3. It’ll be eliminated by unflattenGivens, so there is no problem with scoping. I have no idea whether that’ll help you prove the things you want to prove! Simon From: ghc-devs <ghc-devs-bounces(a)haskell.org<mailto:ghc-devs-bounces@haskell.org>> On Behalf Of Nicolas Frisby Sent: 24 June 2018 19:01 To: ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org> Subject: Can a TC plugin create new skolem vars when simplifying Givens? I'm still spending the occasional weekend working on a type checker plugin for row types (actually "set" types at first, but I haven't thought of a less ambiguous term for that). One point of complexity in the plugin has to do with creating fresh variables when simplifying Givens. Some constraints are traditionally simplified by introducing a fresh variable. For Wanted constraints, that's easy (newFlexiTyVar). For Givens, though, I haven't figured out how to do it. This email is just to ask these two questions: 1) Is there a function to add a new skolem variable when simplifying Givens? 2) Assuming not, is there a strong reason for there to never be such a function? Here's a small indicative example. In the "simplify Givens" step, the plugin receives [G] (p `Union` Singleton A) ~ (q `Union` Singleton B) and I would ideally simplify that to [G] p ~ (x `Union` Singleton B) [G] q ~ (x `Union` Singleton A) for some fresh skolem variable x. But I don't see how to properly create a fresh skolem variable in the Givens. If these were Wanteds, I would just use newFlexiTyVar. I think this is analogous to a hypothetical type checker plugin that eta expands tuples. If we were to simplify [G] ... (x :: (k1,k2)) ... to [G] ... '(x1 :: k1,x2 :: k2) ... we'd have to generate x1 and x2 somehow. The only method I'm aware of for that is to use Fst x and Snd x instead (ie type families). That might be acceptable for the tuple expansion example, but I'm very reticent to use something like that for the set types plugin. I have a plan to get by without creating these variables when simplifying Givens, but it's not simple. I'd be delighted if it were possible to create them. Hence my two questions listed above. Thank you for your time. -Nick

1 0

[ANNOUNCE] GHC 8.6.1-alpha1 available
by Ben Gamari 11 Jul '18

11 Jul '18

The GHC development team is pleased to announce the first alpha release leading up to GHC 8.6.1. The usual release artifacts are available from https://downloads.haskell.org/~ghc/8.6.1-alpha1 This is the first release (partially) generated using our new CI infrastructure. One known issue is that the haddock documentation is currently unavailable. This will be fixed in the next alpha release. Do let us know if you spot anything else amiss. As always, do let us know if you encounter any trouble in the course of testing. Thanks for your help! Cheers, - Ben

4 6

Re: How to use ghc-heap-view of ghc-8.6
by Patrick Dougherty 07 Jul '18

07 Jul '18

Hello, This effort mostly just brought the core of this [1] library into GHC. The main function you will want to try is `getClosureData`,which takes any value and returns the heap representation. There are some tricky aspects about evaluation, but I will refer you to the comments about `Box`s in [1]. As a shameless self-plug, I also wrote a bit about it. The first page is a brief intro to the heap, and the second is an example demonstrating how to track down a leaky accumulator. I also link to a few posts that sent me down this path. This doesn't implement all of the functionality of [1], but it pulls in enough that hopefully it should be a little more stable between GHC versions. Also, you should be able to recreate many of the functions by looking at the source of [1] on hackage. [1] http://hackage.haskell.org/package/ghc-heap-view-0.5.10/docs/GHC-HeapView.h… [2] https://patrickdoc.github.io/heap-view.html Best,Patrick P.S. Sorry about using [1] so many times. Both libraries are called heap-view which makes it a little difficult to distinguish. On Friday, July 6, 2018 10:10 PM, Takenobu Tani <takenobu.hs(a)gmail.com> wrote: Dear devs, I'm interested in ghc-heap-view of ghc-8.6. [1] Is there a document on how to use the ghc-heap-view of ghc-8.6? [1]: https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.6.1#Landedinmasterbranch Regards, Takenobu _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

3 3

How to use ghc-heap-view of ghc-8.6
by Takenobu Tani 07 Jul '18

07 Jul '18

Dear devs, I'm interested in ghc-heap-view of ghc-8.6. [1] Is there a document on how to use the ghc-heap-view of ghc-8.6? [1]: https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.6.1#Landedinmasterbranch Regards, Takenobu

1 0

Diagonally in Data.Bimap
by Gabor Greif 05 Jul '18

05 Jul '18

Hi! Just searched for a `bimap` variant that simultaneously transforms both components with the same morphism: ``` haskell diag :: Bifunctor p => (a -> b) -> p a a -> p b b diag f = bimap f f ``` I did not find any. Would it make sense to add it? Cheers, Gabor PS: same for profunctors: ``` haskell xmap :: Profunctor p => (a -> b) -> p b a -> p a b ``` PPS: I would have sent this to libraries(a)haskell.org but it seem to be closed group.

2 1

Issues with the large address space allocator and HPC systems with resource limits
by Luis Pedro Coelho 05 Jul '18

05 Jul '18

Dear GHC devs, I hope this is the right forum to bring this up. I am the lead developer of NGLess (https://github.com/ngless-toolkit/ngless a bioinformatics tool, written in Haskell). Several users have complained about not being able to easily use NGLess in an academic cluster environment due to the fact that it allocates 1TB of address space (e.g., https://groups.google.com/forum/#!topic/ngless/9su2E0EdeCc and I have also gotten several private emails on this issue). In particular, many systems are set up with a limit on the address space so that if the job allocates more than the given limit, it is immediately killed. This appears to be the default way to set up SGE, the most widely used batch system. Users are dependent on their sysadmins and lack the permissions to change these settings easily (and may not always be cognizant of the difference between "allocating address space" and "allocating memory"). Using ulimit seem to make the issue disappear on most, but not all, user setups. I have now built NGLess with a version of GHC that was compiled without the large address allocator (using ./configure --disable-large-address-space). At least locally, this seems to run correctly and solve the issue. I assume that there are performance or other reasons to use the large address space allocator as the default, but, right now, for the problem space I am working in, disabling it seems to be a better trade-off. In principle, the RTS that is used for GHC and the one that is used for the programme being linked do not need to be the same. Is there any possibility of making this choice when a programme is linked and not when GHC is compiled? Thank you for all your effort! Luis -- Luis Pedro Coelho | Fudan University | http://luispedro.org PI of Big Data Biology Lab at Fudan University (start mid-2018) http://big-data-biology.org

3 3

Not possible to build debug + prof, oversight or expected?
by Ömer Sinan Ağacan 04 Jul '18

04 Jul '18

I just realized GHC 8.4.2 doesn't ship a debug + prof RTS, and HEAD doesn't build it with release build (no build.mk) or with prof flavor. It seems to me that this is a bug, because some debug files in RTS (e.g. Printer.c) actually check PROFILING macro in a few places and print different stuff depending on that. Anyone know if this is intentional? It's really inconvenient that I can't use debug runtime to debug profiling build issues.. (I also realized that we dont' generate .sos for some ways, which means -dynamic is also don't combine with e.g. -prof) Thanks Ömer

2 1

Loading GHC into GHCi (and ghcid)
by Matthew Pickering 04 Jul '18

04 Jul '18

Hi all, Csongor has informed me that he has worked out how to load GHC into GHCi which can then be used with ghcid for a more interactive development experience. 1. Put this .ghci file in compiler/ https://gist.github.com/mpickering/73749e7783f40cc762fec171b879704c 2. Run "../inplace/bin/ghc-stage2 --interactive -odir tmp -hidir tmp" from inside compiler/ It may take a while and require a little bit of memory but in the end all 500 or so modules will be loaded. It can also be used with ghcid. ghcid -c "../inplace/bin/ghc-stage2 --interactive -odir tmp -hidir tmp" Hopefully someone who has more RAM than I. Can anyone suggest the suitable place on the wiki for this information? Cheers, Matt

9 17

req_interp tests
by Ömer Sinan Ağacan 02 Jul '18

02 Jul '18

Hi, I have a few problems with req_interp tests. First, req_interp doesn't actually skip the test, it runs it but expects it to fail. This causes problems when testing stage 1 compiler because 629 req_interp tests are run for no reason. Ideally I think req_interp would skip the test, and for the error messages ("not build for interactive use" etc.) we'd have a few stage 1 tests (maybe we alrady have this). This would make the testsuite much faster for testing stage 1. Second, combination of req_interp and compile_fail currently doesn't work, because req_interp makes a failing test pass, but compile_fail expects the test to fail. See T3953 as an example. Making req_interp skip the test fixes this problem as well. So I'd like to make req_interp skip the test instead of expecting it to fail. Any objections to this? Ömer

2 1