- ghc-devs - Haskell.org

Unsubscribe
by dongen 20 Oct '15

20 Oct '15

Unsubscribe

1 0

GHC Weekly News - 2015/10/16
by Austin Seipp 17 Oct '15

17 Oct '15

(This post is available online at https://ghc.haskell.org/trac/ghc/blog/weekly20151016) Hi *, Welcome for the latest entry in the GHC Weekly News, which has been somewhat irregularly scheduled - but we're as busy as ever! == 8.0.1 release roadmap == We're still steaming ahead on GHC 8.0.1 - any interested participants are suggested to look at the wiki:Status/GHC-8.0.1 page, to see where we're currently at. These past few weeks have been good: we've gotten the first part of the overloaded record fields work in, and we have plans to land the kind equalities work in November. Furthermore, Simon Marlow, Peter Wortmann and Ben are working on reviewing all of the DWARF improvements, and hopefully the start of this work will land next week. But 8.0 isn't the only thing that'll be getting released... == And some other minor releases == In a total, unprecedented upset - we're aiming to do ''three'' GHC releases in a fairly short amount of time. === 7.10.3 === Ben Gamari has been working on steadily hacking away at GHC 7.10.3, and the hopes are that we'll be able to ship it soon. This will fix several dozen bugs, some of which are critical for our users. You can keep up to date by following the wiki:Status/GHC-7.10.3 page. === 7.8.5 === Simultaneously, your author will ''also'' be working on a GHC 7.8.5 release. While we were alerted a few months ago to this breakage, it seems rather unfortunate for the 7.8 series to remain broken on such a popular OS. Furthermore, the "Three GHC Release Policy" for many authors - to support the last three major versions of GHC - would mean that 7.8 would be broken for OS X developers for an ''entire year until GHC 8.2.1''. Which is a pretty unfortunate circumstance. It's not expected the 7.8.5 release will contain any other fixes, however. == List chatter == (Over the past two weeks) - Ben Gamari wrote in about '''switching the users guide to reStructuredText''', and the TL;DR is - it's done! We'll have a beautiful new users guide for GHC 8.0.1 https://mail.haskell.org/pipermail/ghc-devs/2015-October/010029.html - Matthew Pickering comments about the state of pattern synonym signatures, remarking that they're currently confusing, noting down some things we could possibly fix. https://mail.haskell.org/pipermail/ghc-devs/2015-October/010024.html - Ben Gamari talked about the status of the recent DWARF work, and so far it's looking good. The needed patches are still in the review pipeline, but the hope is that they'll all be done in time for 8.0.1. https://mail.haskell.org/pipermail/ghc-devs/2015-October/010039.html - David A Roberts wrote in to ask a question: now that we have `ApplicativeDo`, what about `Applicative` comprehensions? The responses indicate this seems like it would be a great addition. https://mail.haskell.org/pipermail/ghc-devs/2015-October/010062.html - Richard Eisenberg sent in a status update about his work on kind equalities, and the hope is it will land shortly in November! (Your editor then hassled him for a syntax change before landing.) https://mail.haskell.org/pipermail/ghc-devs/2015-October/010077.html - Adam Foltzer has requested another release of the GHC 7.8 series, due to it being completely broken on OS X El Capitan. Expect more news on this soon. https://mail.haskell.org/pipermail/ghc-devs/2015-October/010078.html - Erik de Castro Lopo has recently been working with LLVM, and decided to publish his automation so interested GHC hackers could keep up to date and try new LLVMs easily. https://mail.haskell.org/pipermail/ghc-devs/2015-October/010086.html == Noteworthy commits == (Over the past two weeks) - Commit 4fd6207ec6960c429e6a1bcbe0282f625010f52a - Move the users guide to reStructured Text. - Commit 6cde981a8788b225819be28659caddc35b77972d - Make `GHC.Generics` capable of handling unboxed tuples. - Commit 0eb8fcd94b29ee9997b386e64203037bdf2aaa04 - Enable `Enumeration is empty` warnings for `Integer` - Commit 620fc6f909cd6e51b5613454097ec1c9f323839a - Make Windows linker more robust to unknown sections - Commit 5d841108acef950fed6a5e608ac9b18e7431aa87 - Add short library names support to the Windows linker - Commit f8fbf385b879fe177409a25cc9499275ea3dc45d - Reinstate monomorphism-restriction warnings - Commit dcc342870b4d8a739ccbed3ae26e84dcc3579914 - Don't inline/apply other rules when simplifying a rule RHS. - Commit dec5cd4085488686b5ed50bb26ccbc0ba7b645ec - base: Add `forkOSWithUnmask` - Commit e8c8173923302268ef950c3b21e276779e45ac83 - Allow arr ∧ (first ∨ (***)) as minimal definition of Arrow instance - Commit 29310b622801733e1b29a9a61988406872db13ca - Switch to LLVM version 3.7 - Commit 04e8366608fee4f5e3358acc855bc6f556c3f508 - ELF/x86_64: map object file sections separately into the low 2GB - Commit b1884b0e62f62e3c0859515c4137124ab0c9560e - Implement `DuplicateRecordFields` - Commit 75492e7467ff962f2f2e29e5c8b2c588c94ae8a7 - Add typed holes support in Template Haskell. - Commit 6a8ca65032c6b3ed61b5378765e70120083cf5da - Allow left ∨ (+++) as minimal definition of ArrowChoice instance == Closed tickets == (Over the past two weeks) #10392, #7883, #10475, #10745, #10926, #9238, #10700, #10810, #10342, #365(!), #10361, #10929, #10563, #9907, #10513, #10868, #10932, #8920, #10516, #10416, #5966, #8335, #10520, #10687, #10571, #9058, #10939, #10938, #9590, #10949, #10153, #10947, #10948, #10936, #1883, #5289, #10733, #10950, #10611, #10959, #10960, #10831, #10796, #10890, #8010, #10216, #10965, #10953, #10964, #10931, #10714, #10888, #10633, #8652, #3971, #10882, #10977, #10267, and #10911. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

Request to reopen the issue of 7.8 on El Capitan
by Adam Foltzer 16 Oct '15

16 Oct '15

Hello, The issue was brought up on this list [1] that the released versions of GHC 7.8 do not work on El Capitan due to an older `unix` package. In a subsequent GHC weekly news [2], it was announced that since El Capitan wasn't yet released, it wasn't worthwhile to put more developer time into 7.8. Now that El Capitan is out, and the existing 7.8 binaries continue to not work, I'd like to reopen this issue and request a point release with an updated `unix` package. Thank you, Adam Foltzer Research Engineer Galois, Inc. [1]: https://mail.haskell.org/pipermail/ghc-devs/2015-July/009403.html [2]: https://ghc.haskell.org/trac/ghc/blog/weekly20150721#MacOSXElCapitansupport

4 6

MonadFail decisions
by Simon Peyton Jones 16 Oct '15

16 Oct '15

Dear Edward and Core Libraries Committee Can you tell us what plan you want to execute for MonadFail? Specifically, in https://wiki.haskell.org/MonadFail_Proposal · Is the specification in 1.3 what you have agreed? · Is the transition strategy in 1.7 exactly what you want? We can’t implement 8.0 without being sure of the specification! The current Phab is https://phabricator.haskell.org/D1248 Also, David, did our conversation at HX help you get un-stuck? Thanks Simon From: haskell-core-libraries(a)googlegroups.com [mailto:haskell-core-libraries@googlegroups.com] On Behalf Of Edward Kmett Sent: 13 October 2015 01:43 To: core-libraries-committee(a)haskell.org Subject: [core libraries] Prelude: 3 Release Policy Recently there has been a bunch of chatter about ways to mitigate the amount of CPP pushed on users by changes to the Prelude. In particular the discussion has been around the idea of trying to ensure that it is possible to write code in _some_ way without CPP that can run backwards for 3 releases of GHC, preferably in a -Wall safe manner. The approach they may have to use may not be the idiomatic way, but in general it should exist. Gershom ran around at the Haskell Exchange sounding folks out about this idea, and it seems to codify a reasonable tension between the "change nothing" and "change everything" camps. The feedback thus far seems to be noises of "grumbling acceptance" rather than the current state of outright panic that we might do anything at any time. I'm personally considering this a very high priority for all changes to Prelude going forward. The 3 years forms a backward-facing window, not a guarantee against future change, but we should of course try to let folks know what is coming with a decent time horizon so folks can look forward as well. That is a separate concern, though. I'm not ready to give the "3 release policy" outright veto power over new functionality, but at least if we have two plans that can in the end yield the same end state, we should definitely err on the side of the plan that falls within these guidelines, and be very well ready to explain to a rather irate community when we violate this rubric. It shouldn't be done lightly, if at all, if we can help it! All in all it is a fairly weak guarantee, but it does have some impact on current items under consideration. Off the top of my head: * A number of new members for Floating were passed by proposal back before 7.10 went out the door, but haven't found their way into base yet: expm1, log1p, etc. are absolutely required for decent precision numerics. When the proposal passed we ultimately decided _not_ to include default definitions for these to force authors to implement them explicitly. Under the guidelines here, the plan would likely have to include default definitions for these to start when introducing them in 8.0. Then in 8.4 we could in theory remove the defaults and remain in compliance with the letter of the law here or introduce an ad hoc warning about lack of implementation, and remove the defaults in 8.6, depending on how gradual an introduction we wanted to give. We wouldn't be able to do the warnings in 8.2, however, and remain within the letter of the law, and we wouldn't be able to introduce them without defaults without violating the no-warnings guideline. * MonadFail reform proposal wouldn't be able to start issuing warnings about missing instances until 8.4 even if we put in MonadFail into a module today. This would likely delay the full implementation of the proposal to 8.6 as well. * The Semigroup as a superclass of Monoid proposal runs into a similar clock. An immediate consequence is that creating a class in base (or moving one into base) and moving it into Prelude changes picks up a 3-4 year window for implementation. (3 years from this guideline, and a year if we want to / should give warnings about missing instances, which as mentioned above, is a separate concern.) Observations: This doesn't imply the lack of warnings for new names coming into Prelude, because code can be changed to use the new names in a backwards compatible way. The AMP warnings would be in compliance. I don't think we can viably apply this reasoning to other modules in base or even most other packages under the core libraries purview: It'd be nice, but things like template-haskell change on too quick a clock. For other modules in base or other libraries in scope of the core libraries process, I'd probably consider this guideline demoted from "should" to "may". When Data.Proxy or Data.Void were brought into base they were brought in more or less unmolested from tagged and void respectively with only minor differences. This means that code that wants to use them with older versions of the compiler can use their pre-existing dependency as a conditional (or mandatory) listed dependency. This means that code that was using them before continues to work fine despite their incorporation into base. Compliance with this rule also acts as a hedge against severe bikeshedding when we incorporate more stuff. In the case of Semigroup you can use the semigroups package today in a form that is backwards compatible for a half dozen We could ship a 'fail' package that gave you access to the MonadFail class across older GHC versions. The question then becomes is it worth trying to use the existence of those packages to try to "cheat the clock"? I think we'd almost assuredly be rightly called out for 'cheating' by package maintainers where a fresh 'fail' package was concerned, but given the widespread distribution of 'semigroups' it might be plausible to use that to justify finishing out that proposal in 8.4 (end of 2017) rather than 8.6 (end of 2018). Personally, I'm content with the longer clock and don't think it'd be worth doing in this case, but it was an informative exercise to consider. At the least, the existence of such packages lets us go much farther back than 3 releases for folks who have a wider support window. Again, the above guideline would basically imply that if you wanted to add a thing to base and get it into the Prelude you can't do it in less than 3 years. Given the stability of Prelude this is the _least_ we can do. Now nobody needs to worry about us rushing off to add Pointed or Semiapplicative to Prelude in the short term. It simply can't move into base and happen that fast. Things already in base could admittedly take a shorter path and comply, but it is worth noting that this is just one guideline -- both the AMP and Foldable/Traversable Proposal would pass this litmus test. I'm mostly just running through active proposals and trying to understand the impact of such a policy, but so far I can't find anything that causes me to object. I'm content to codify it as my own personal "best practice", and would be willing to see us as an organization draft it up into a form that other people could rely upon to get a sense of stability. In all of the above cases I think it actually improves upon the timeline a bit. Lengthening the timelines above means we'll need to work harder on transferring institutional memory at the very least. Wiki and Trac items for these sorts of proposals will become even more important. It will become almost impossible to spawn a from-scratch Prelude-affecting proposal and finish it during one 3-year cycle tenure on the committee. Ideas? -Edward -- 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+unsubscribe(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…>.

4 8

RE: [Differential] [Commented On] D761: Implement DuplicateRecordFields
by Simon Peyton Jones 16 Oct '15

16 Oct '15

Adam | Is it okay for me to go ahead and merge this? I'll resolve | whatever conflicts there are and do a final validate before merging.I think so, yes. You might want to talk to Matthew Pickering, who is scared about the rebase work he'll have to do on https://phabricator.haskell.org/D1152 Simon | -----Original Message----- | From: noreply(a)phabricator.haskell.org | [mailto:noreply@phabricator.haskell.org] | Sent: 16 October 2015 09:13 | To: Simon Peyton Jones | Subject: [Differential] [Commented On] D761: Implement DuplicateRecordFields | | adamgundry added a comment. | | This builds fine on Travis | <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftravis- | ci.org%2fghc%2fghc%2fbuilds%2f85608329&data=01%7c01%7csimonpj%40064d.mgd.mic | rosoft.com%7c97282e9f11ea49d5756708d2d60189cd%7c72f988bf86f141af91ab2d7cd011 | db47%7c1&sdata=HUDXMe7E%2b0sSCQMpaxJMKajAF2EBixcHdnwdnxKLMd4%3d> but not on | Phab, I suspect because the diff needs to be updated to apply cleanly to the | latest HEAD. Is it okay for me to go ahead and merge this? I'll resolve | whatever conflicts there are and do a final validate before merging. | | | REPOSITORY | rGHC Glasgow Haskell Compiler | | REVISION DETAIL | https://phabricator.haskell.org/D761 | | EMAIL PREFERENCES | https://phabricator.haskell.org/settings/panel/emailpreferences/ | | To: adamgundry, goldfire, bgamari, simonpj, austin | Cc: sjcjoosten, haggholm, mpickering, bgamari, tibbe, thomie, goldfire

1 0

Re: Applicative Comprehensions
by Ryan Scott 16 Oct '15

16 Oct '15

There was a feature request made for this on Trac before ApplicativeDo was finished (https://ghc.haskell.org/trac/ghc/ticket/8914) so generalizing monad comprehensions would fix half of Trac #8914. (The other half, which proposes generalizing ParallelListComp, would require an API change, so it might be better to tackle that separately.) Regards, Ryan S.

2 1

Fwd: Strictness/demand analysis without worker/wrapper, or, reviving -fmax-worker-args
by Christiaan Baaij 15 Oct '15

15 Oct '15

Forgot to also send to the list > Begin forwarded message: > > From: Christiaan Baaij <christiaan.baaij(a)gmail.com> > Subject: Re: Strictness/demand analysis without worker/wrapper, or, reviving -fmax-worker-args > Date: 15 Oct 2015 17:27:21 CEST > To: Simon Peyton Jones <simonpj(a)microsoft.com> > > Thanks for the comments, I will create a patch for a -fno-worker-wrapper flag somewhere next week then. > > I’ll also see about reviving -fmax-worker-args. > Although it’s not used by any package on Hackage, and it has been dead for over 2 years now I think. > > — Christiaan > >> On 14 Oct 2015, at 14:02, Simon Peyton Jones <simonpj(a)microsoft.com> wrote: >> >> Some quick thoughts: >> >> * It would make perfect sense to run the demand analyser without the worker/wrapper transform, yes. By all means make a patch to make that easy to do. Do NOT do this by setting -fmax-worker-args=0; that would be a hack even if it worked; and as you say it probably doesn't. >> >> * The -fmax-worker-args flag is supposed to stop GHC unpacking a function with a zillion fields. E.g. suppose we have >> f :: (Int,Int,Int, ..., Int, Int) -> Int >> which, say, adds up all the field of a 200-tuple. It would probably gain little to worker/wrapper this, because the worker would get 200 arguments. Maybe that's ok, but the gain over allocating the arg tuple in the heap is proportionately less. >> >> But clearly some refactoring lost this ability. Maybe someone should put it back! >> >> I have no evidence, either way, to suggest that limiting the # of args to a worker would be beneficial. Just a kind of intuition. >> >> >> Simon >> >> >> | As a GHC API user, I would like to run GHC’s strictness and demand analysis >> | pass, but I don’t want any worker/wrappers. >> | My specific use-case is to generate digital circuits from Haskell code, >> | where I’ve yet to encounter any benefit from worker/wrappers: the generated >> | circuits do not get any smaller or faster. >> | They do however induce longer compilation times for my compiler. >> | I still want to have GHC’s strictness and demand analysis, because, if I >> | understand correctly, the demand and strictness annotations are needed by >> | GHC’s dead code analysis (and other optimisations) which is beneficial for >> | my use case. >> | >> | Looking through DynFlags, I encountered the ‘maxWorkerArgs’ field, which is >> | controlled by ‘-fmax-worker-args’. >> | The user guide says the following: >> | "If a worker has that many arguments, none will be unpacked anymore >> | (default: 10)” >> | I don’t know exactly what this means, but I was hoping that if I would set >> | that number to 0 (zero), no worker/wrapper pairs would be created. >> | Is that correct? >> | >> | The reason that I’m asking is because -fmax-worker-args is basically dead >> | code. >> | The ‘maxWorkerArgs’ field of DynFlags is not used anywhere. >> | If setting ‘-fmax-worker-args’ to zero does indeed prevent any >> | worker/wrappers from being generated, should I reimplement the flag and >> | submit it as a patch? >> | Or, is it preferable to simply remove ‘-fmax-worker-args’ (given that it >> | doesn’t do anything right now), and create a new flag, ‘-fno-worker- >> | wrapper’, that simply disables the creation of worker/wrapper pairs >> | everywhere? >> | >> | Regards, >> | >> | Christiaan >> | _______________________________________________ >> | ghc-devs mailing list >> | ghc-devs(a)haskell.org >> | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell >> | .org%2fcgi-bin%2fmailman%2flistinfo%2fghc- >> | devs%0a&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c6c87f8a67afa4d8c78 >> | 8108d2d3238a16%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=vk8RNAbzZpj63RRu >> | SQV%2fPDS7trt6puHaEhXBSHbIZQ0%3d >

1 0

Applicative Comprehensions
by David A Roberts 15 Oct '15

15 Oct '15

Hi, I raised this question on #haskell, and was advised that this was probably the best place to discuss. I see that Applicative Do is scheduled for GHC 8.0 [1], and was hoping that this might also enable support for Applicative Comprehensions [2]. Is this likely to be the case? If not, would it be difficult to extend the support for Applicative Do to also handle comprehensions? I'm willing to submit patches if necessary, but I'm not at all familiar with GHC internals, so would need some guidance. I understand that comprehensions tend not to be used much in idiomatic Haskell, but I find them to be useful for implementing DSLs, so would really like to see this be supported. For example, a matrix could be written in a familiar notation: > [ i + 2*j | i <- rows, j <- cols ] which is a little more readable (to those not familiar with Haskell) than > (\i j -> i + 2*j) <$> row <*> cols or > do { i <- rows; j <- cols; return (i + 2*j) } [1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1#LandedinHEAD [2] https://ghc.haskell.org/trac/ghc/wiki/GeneralizedMonadComprehensions#Applic… -- David A Roberts https://davidar.io

7 6

Re: GHC and LLVM
by Erik de Castro Lopo 15 Oct '15

15 Oct '15

Manuel M T Chakravarty wrote: > That sounds great. Can your Jenkins instance maybe also push > the reports to one of the GHC lists, so everybody can see what > the state of play is? Well currently the report log is 7Meg and I'm sure everyone would appreciate it if I kept those to myself. Currently the state of play can be seen from the patches listed here: https://github.com/erikd/ghc-llvm-next/tree/master/patches These are the patches that currently need to be applied to GHC git HEAD to build it against LLVM git head. The first, 00-configure-3.8.patch switches GHC from using LLVM 3.7 to using 3.8. The second, 01-bitcast.patch is needed because the syntax of the bitcast operation has changed in some situations. The number of tests failing with this setup is the same as the number failing with GHC git head compiled against the 3.7 (and 3.6) release of LLVM. Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

1 0

GHC and LLVM
by Erik de Castro Lopo 15 Oct '15

15 Oct '15

Hi all, As some of you may have noticed the LLVM requirements for GHC HEAD has just switched from version 3.6 to 3.7. This was mainly to support Arm64 (aka AArch64 aka Armv8-a), for which llvm-3.6 was badly broken. Since figuring out what needed to change from 3.6 to 3.7 was rather painful, I decided to set up a small project to help us GHC devs keep up with what happens in the LLVM dev world. http://github.com/erikd/ghc-llvm-next/ The project is a build script (actually a Makefile) and a set of patches) which does the followiing: * clones/updates LLVM from git, builds it and installs it locally * clones/updates GHC from git * applies patches git GHC so that GHC builds against the locally build LLVM tools. * builds GHC and then runs the testsuite I plan on running the above build on a daily basis in my own personal Jenkins instance in order to track changes in GHC and LLVM. Others are free to do the same and I'm happy to take pull requests. This project may also be interesting or useful for people testing out up-coming LLVM features with GHC. Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

2 1