October 2015 - ghc-devs

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 14 Oct '15

14 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

Kind equalities update
by Richard Eisenberg 14 Oct '15

14 Oct '15

Hi devs, In a chat with Simon this morning about kind equalities, he expressed that you all might want to know about the plans for kind equalities in 8.0. The wiki page both for user-facing changes and for implementation notes is here: https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Phase1 It is my intent that all user-facing changes mentioned there will be available in 8.0. I am hard at work getting my branch ready to merge, and hope to do so mid-November. Note: this is almost fully backward-compatible. Here are some areas where there are known incompatibilities: - Template Haskell will have to be updated. But there's a raft of changes there, anyway. - GHC will do a more careful job of checking for termination of instances regarding the use of kind variables. This may require new UndecidableInstances declarations. But the fact that these definitions (like `instance (C a, C b) => C (a b)` for a polykinded C) were accepted previously could be called a bug. That's actually all I know of so far. You can take kind equalities for a spin at github.com/goldfirere/ghc, on the "nokinds" branch. Note that this hasn't been merged with `master` since December of last year, so expect a little strange behavior compared with 7.10. These wrinkles will get smoothed out, of course. Richard

5 6

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

14 Oct '15

Hi, 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

2 1

HEADS UP: HCAR due at the end of this month
by Austin Seipp 13 Oct '15

13 Oct '15

Hi *, The November edition of the HCAR is soon, so it's that time of the year again! https://ghc.haskell.org/trac/ghc/wiki/Status/Oct15 I've gone ahead and taken most of the basic info directly from the 8.0.1 status page. Everyone, please take 5 minutes to read over this page and make sure whatever you want mentioned is there. Remember: this is *not* the status report for 8.0 necessarily - so if you have something planned after 8.0 that you're working on, go ahead and add it! I'll be touching up the markup etc to bring it in line with what we usually have (bold highlights, etc). In the mean time, just write your blurb - I'll do the wordsmithing for the final draft... -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

(Don't) remove unused flags? [#10935]
by Alexander Berntsen 10 Oct '15

10 Oct '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 I want to tackle [0], but I disagree with the proposed solution. At least with regards to the first three flags. Instead, I want to make the flags work. Thoughts? [0] <https://ghc.haskell.org/trac/ghc/ticket/10935> - -- Alexander alexander(a)plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJWGO9CAAoJENQqWdRUGk8BUiMP/1PfMfXr4p1jWCasPHvWMrXj Ep0/e5boThJs3bsD+xf1eVl2NIjT4dAONO7zI7PkohvkjbgjXGWFE+SDJKI6iWXV Kb06GM73q7vBL3sL45SFy8/tofn0J//jSAkXoNzJ64Nlny2xXxLg91e0mj79fbGx Y3rwv7SB9ZpBm/ov41PtiX5+5hc3mWDwZS/+UIUj1tUdfFHk8BR4HMEXEfihU0mh yrxdPHWsAYmIPYfoE/9HAbQ6SqynUErW8kOrr47/kZO0yBl2xkK7XvA7I0fy0upG HS6teTcxtVmzFFPBrDvZGEz0cawT56/jpMBNHNgkLUOF3lssjLpMCl3KyoJXV9PB kaHxICISubBsLoIZti/MQBshjwbLzT6MCItMIlD77w21mp3MEqiFQ9+M+ePCwGp8 WmX5iAFc8ze6bku51cYGSxiIjIMcpJVNI4Sr+8aRFuFBUqiOe/GKn0t5UvyPMekb FTcYLH4JKjBEXkkuF2WWr+Ey+d87XQ1ioN+wwg+v2pFGP4NtwepoNbYsQG4WbHYx gFAdWAnirsdSrio5VTZWVz05ouIIUG6CtDM6QfaC3EUCLDWePz+fd63U+gjO3A4s AW8Rfm/rDQBNs7USIgODjKdDtGwAJM4i+PxypWW8rg9sfOBwGEcS8XngphxWb6pp bHkPHy6k+vGOrZUUSMFb =B8HY -----END PGP SIGNATURE-----

1 0