- ghc-devs - Haskell.org

Proposal: Turn on ScopedTypeVariables by default
by David Feuer 24 Feb '15

24 Feb '15

I know this will be controversial, because it can break (weird) code and because it's not Haskell 2010, but hey, you can't make brain salad without breaking a few heads. ScopedTypeVariables is just awesome for two fundamental reasons: 1. It lets you write type signatures for more things. 2. It lets you write more precise type signatures for many things. As a consequence of those two, 3. It helps you get much better error messages from the type checker. And for all that, 4. It's really easy to use. What do other people think?

5 4

Docs of the daily builds broken
by Joachim Breitner 24 Feb '15

24 Feb '15

Hi, while the index at http://haskell.inf.elte.hu/docs/7.11.20150222.noWin32/html/libraries/index.… exists, navigating to http://haskell.inf.elte.hu/docs/7.11.20150222.noWin32/html/libraries/Data-C… yields a 404 error. Same for http://haskell.inf.elte.hu/docs/latest/html/libraries/Data-Char.html Additinally, the wiki page at https://ghc.haskell.org/trac/ghc/wiki/BuilderSummary does not list a point of contact for this (and I regularly forget these things. Was it Gabor?). Whoever runs this: Good job! Make sure you take the credit! :-) Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

2 1

RE: GHC Type Inference
by Simon Peyton Jones 24 Feb '15

24 Feb '15

Marc For type-level literals, the man to talk to is Iavor Diatchki. He implemented the current system, and has been working on enhancements. I'm sure he'd welcome help! There's also quite an active sub-group (on ghc-devs) working on "plug-ins" for the type inference algorithm, aimed at allowing things like better arithmetic reasoning to be done without having to change GHC itself. Simon | -----Original Message----- | From: dongen [mailto:dongen@cs.ucc.ie] | Sent: 23 February 2015 10:54 | To: Simon Peyton Jones | Cc: ghc-devs(a)haskell.org | Subject: GHC Type Inference | | Dear Simon, | | | I am cc-ing _ghc-devs@haskell.org_ as requested on _ghc.haskell.org_. | | I hope you're fine. | | On _ghc.haskell.org_ I noticed you are the ``owner'' of _type | inference and interface files._ | | A year ago I started a project that requires integer type-level | literals but I soon had to drop it because GHC wasn't able to | simplify simple type equalities. As a consequence, I had to | add lots and lots of constraints to make my code work, which | effectively meant the code became unmaintainable because a small | change requlted in lots of errors. | | I know have a bit more time to work on the project and I'd like | to see if it's possible to ``talk'' to somebody in the GHC team | to see if we can improve type-level literal inference for natural | numbers. | | Is there somebody who's ``responsible'' for this area in the GHC | team? If yes, would you mind giving me their contact details? | | Regards, | | | Marc van Dongen

2 1

GHC Weekly News - 2015/02/23
by Austin Seipp 23 Feb '15

23 Feb '15

(This post is available online at https://ghc.haskell.org/trac/ghc/blog/edit/weekly20150223) Hi *, It's once again time for your sometimes-slightly-irregularly-scheduled GHC news! This past Friday marked the end of the FTP vote for GHC 7.10, there's an RC on the way (see below), we've closed out a good set of patches and tickets from users and pushed them into `HEAD`, and to top it off - it's your editor's birthday today, so that's nice! Quick note: as said above GHC HQ is expecting to make a '''third''' release candidate for GHC 7.10.1 soon in early March since the delay has allowed us to pick up some more changes and bugfixes. We plan on the final release being close to the end of March (previously end of February). This week, GHC HQ met up again to discuss and write down our current priorities and thoughts: - After discussing our current timetable - as we're currently hovering around the ICFP deadline - we're hoping to make our third GHC 7.10.1 release candidate on '''Friday, March 13th''', with the final release on '''Friday, March 27th'''. This was the main take away from our meeting today. We've also had a little more list activity this week than we did before: - The FTP debate has ended, and the results are in: GHC 7.10.1 will continue with the generalized Prelude, known as "Plan FTP". https://mail.haskell.org/pipermail/libraries/2015-February/025009.html - Edward Kmett announced the `directory` package needed an active maintainer to step up - and luckily, Phil Ruffwind and Elliot Robinson did just that and stepped up as maintainers! https://mail.haskell.org/pipermail/ghc-devs/2015-February/008358.html - Kazu Yamamoto asked about a behavioral change in `ghc-7.10` for `Data.Char` - it turns out this difference looks like it's caused by GHC 7.10 shipping an update to use Unicode 7.0 datasets. https://mail.haskell.org/pipermail/ghc-devs/2015-February/008371.html - Thomas Bereknyei asked about a fundamental change in the Arrow desugarer, and whether or not something like this was worth it. Jan Stolarek and Ross Paterson stepped in to speak up to some specifics Thomas had about. https://mail.haskell.org/pipermail/ghc-devs/2015-February/008377.html - Gabor Grief spoke up about strange behavior in the desugarer when using `RebindableSyntax` and `RankNTypes`, which Adam Gundry popped in to say may be a deeper issue due to the way typechecking and desugaring interact - https://mail.haskell.org/pipermail/ghc-devs/2015-February/008383.html - Johan Tibell announced Cabal 1.22.1.0, which will ship with GHC 7.10. https://mail.haskell.org/pipermail/ghc-devs/2015-February/008388.html Some noteworthy commits that went into `ghc.git` in the past week include: - Commit 1b82619bc2ff36341d916c56b0cd67a378a9c222 - The `hpc` commands now take a configurable verbosity level (merged to `ghc-7.10) - Commit 0fa20726b0587530712677e50a56c2b03ba43095 - GHC now errors out on a module explicitly declared `Main` without a `main` export. Closed tickets the past week include: #9266, #10095, #9959, #10086, #9094, #9606, #9402, #10093, #9054, #10102, #4366, #7604, #9103, #10104, #7765, #7103, #10051, #7056, #9907, #10078, #10096, #10072, #10043, #9926, #10088, #10091, #8309, #9049, #9895, and #8539. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

FYI: Cabal-1.22.1.0 has been released
by Johan Tibell 23 Feb '15

23 Feb '15

We will probably want to ship that with GHC 7.10.

6 8

Writing a subtype function
by Izzy Meckler 23 Feb '15

23 Feb '15

Hi all, I apologize if this isn’t the right place for this sort of question, but I’m at a loss as to how to use TcUnify.tcSubType. My goal is to write a function of type Type -> Type -> Ghc Bool which checks whether the first argument is a subtype of the second. I assume this is possible to do using TcUnify.tcSubType and runTcInteractive, but it’s not clear to me how. Any pointers here would be greatly appreciated.

2 2

Desugaring introduces
by Gabor Greif 23 Feb '15

23 Feb '15

Hi devs, before I file a bug, I'd like to double check on a strange desugaring behaviour with RankNTypes and RebindableSyntax. Here is the snippet {{{ {-# LANGUAGE RankNTypes, RebindableSyntax #-} {-# LANGUAGE ImpredicativeTypes #-} import qualified Prelude as P (>>=) :: a -> ((forall b . b) -> c) -> c a >>= f = f P.undefined return a = a fail s = P.undefined t1 = 'd' >>= (\_ -> 'k') t2 = do _ <- 'd' 'k' main = P.putStrLn [t1, t2] }}} Without ImpredicativeTypes I get this error: {{{ rebindtest.hs:13:9: Cannot instantiate unification variable ‘t0’ with a type involving foralls: forall b. b Perhaps you want ImpredicativeTypes In a stmt of a 'do' block: _ <- 'd' In the expression: do { _ <- 'd'; 'k' } In an equation for ‘t2’: t2 = do { _ <- 'd'; 'k' } }}} t1 is supposed to be the desugaring of t2. Strangely t2 only compiles with ImpredicativeTypes. Why? Isn't desugaring a purely syntactic transformation (esp. with RebindableSyntax)? Any hints welcome! Cheers, Gabor

3 3

Re: ANNOUNCE: GHC 7.10.1 Release Candidate 2
by Miëtek Bak 21 Feb '15

21 Feb '15

My previous email was about the x86_64 bindist GHC 7.10.1-rc2. I’ve now added i386 support to Halcyon, and it appears only the x86_64 version works fine on CentOS 6 (6.5), while the i386 version fails to configure: checking for path to top of build tree... utils/ghc-pwd/dist-install/build/tmp/ghc-pwd: symbol lookup error: libraries/integer-gmp2/dist-install/build/libHSinteg_21cuTlnn00eFNd4GMrxOMi-ghc7.10.0.20150123.so: undefined symbol: __gmpn_andn_n configure: error: cannot determine current directory -- Miëtek On 2015-01-27, at 06:26, Miëtek Bak <mietek(a)bak.io> wrote: > It appears GHC 7.10.1-rc2 doesn’t support glibc 2.11 — specifically, 2.11.1 (Ubuntu 10.04 LTS) and 2.11.3 (Debian 6). glibc 2.12 (CentOS 6) seems to work fine. Symptoms include: > > Installing library in > /app/ghc/lib/ghc-7.10.0.20150123/ghc_0kOYffGYd794400D7yvIjm > "/app/ghc/lib/ghc-7.10.0.20150123/bin/ghc-pkg" --force --global-package-db "/app/ghc/lib/ghc-7.10.0.20150123/package.conf.d" update rts/dist/package.conf.install > Reading package info from "rts/dist/package.conf.install" ... done. > "utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" register libraries/ghc-prim dist-install "/app/ghc/lib/ghc-7.10.0.20150123/bin/ghc" "/app/ghc/lib/ghc-7.10.0.20150123/bin/ghc-pkg" "/app/ghc/lib/ghc-7.10.0.20150123" '' '/app/ghc' '/app/ghc/lib/ghc-7.10.0.20150123' '/app/ghc/share/doc/ghc/html/libraries' NO > Warning: cannot determine version of /app/ghc/lib/ghc-7.10.0.20150123/bin/ghc > : > "" > ghc-cabal: '/app/ghc/lib/ghc-7.10.0.20150123/bin/ghc' exited with an error: > /app/ghc/lib/ghc-7.10.0.20150123/bin/ghc: symbol lookup error: > /app/ghc/lib/ghc-7.10.0.20150123/bin/../rts/libHSrts_thr-ghc7.10.0.20150123.so: > undefined symbol: pthread_setname_np > > The bindist name does mention 'deb7', so perhaps this is all working as intended. However, similarly named bindists for GHC 7.8.* work fine with glibc 2.11. > > > In other news, I’m happy to say Halcyon now supports GHC 7.10.1-rc2 on CentOS 6 and 7, Debian 7, Fedora 19, 20, and 21, and Ubuntu 12 and 14. > https://halcyon.sh/ > > $ halcyon install --ghc-version=7.10.1-rc2 --cabal-version=1.22.0.0 > > > Best, > > -- > Miëtek > > > > > On 2015-01-27, at 00:13, Austin Seipp <austin(a)well-typed.com> wrote: > >> We are pleased to announce the second release candidate for GHC 7.10.1: >> >> https://downloads.haskell.org/~ghc/7.10.1-rc2/ >> >> This includes the source tarball and bindists for 64bit/32bit Linux >> and Windows. Binary builds for other platforms will be available >> shortly. (CentOS 6.5 binaries are not available at this time like they >> were for 7.8.x). These binaries and tarballs have an accompanying >> SHA256SUMS file signed by my GPG key id (0x3B58D86F). >> >> We plan to make the 7.10.1 release sometime in February of 2015. >> >> Please test as much as possible; bugs are much cheaper if we find them >> before the release! >> >> -- >> Regards, >> >> Austin Seipp, Haskell Consultant >> Well-Typed LLP, http://www.well-typed.com/ >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs(a)haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 1

Re: Behavior change of Data.Char
by David Feuer 20 Feb '15

20 Feb '15

I don't think so. There's no guarantee that future versions will maintain it, and I don't know that we want to take responsibility for continually checking on that. David On Feb 20, 2015 Simon Peyton Jones wrote: > It'd be good to document this condition/invariant in the Haddocks, wouldn't it?! > > Simon > > | -----Original Message----- > | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of > | Herbert Valerio Riedel > | Sent: 19 February 2015 10:42 > | To: Kazu Yamamoto > | Cc: libraries(a)haskell.org; ghc-devs(a)haskell.org > | Subject: Re: Behavior change of Data.Char > | > | On 2015-02-19 at 06:19:18 +0100, Kazu Yamamoto (????) wrote: > | > It seems to me that some characters of GHC 7.10.1RC2 behave > | > differently from those of GHC 7.8.4: > | > > | > 7.8.4 7.10.1RC2 > | > isLower (char 170) True False > | > | Fwiw, the motivation for that particular change may be (I'm just > | guessing here) to have the following condition hold: > | > | \c -> isLower c `implies` (not . isLower . toUpper) c > | > | i.e. if something is 'lower-case', then applying 'toUpper' should > | result in a character that is not 'lower-case' anymore. This didn't > | hold with 7.8.4's Unicode 6, but now holds with 7.10.1's Unicode 7 > | definitions. > | > | Cheers, > | hvr > | _______________________________________________ > | ghc-devs mailing list > | ghc-devs(a)haskell.org > | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

2 1

76-fold regression GHC 7.10->7.11 in T9961 byte-allocation
by Herbert Valerio Riedel 20 Feb '15

20 Feb '15

Hello *, I noticed something odd while validating the GHC 7.10 branch: bytes allocated value is too low: (If this is because you have improved GHC, please update the test so that GHC doesn't regress again) Expected T9961(normal) bytes allocated: 772510192 +/-5% Lower bound T9961(normal) bytes allocated: 733884682 Upper bound T9961(normal) bytes allocated: 811135702 Actual T9961(normal) bytes allocated: 9766160 Deviation T9961(normal) bytes allocated: -98.7 % *** unexpected stat test failure for T9961(normal) ...then I also ran ./validate against today's GHC HEAD, and re-ran the T9961 test: Expected T9961(normal) bytes allocated: 772510192 +/-5% Lower bound T9961(normal) bytes allocated: 733884682 Upper bound T9961(normal) bytes allocated: 811135702 Actual T9961(normal) bytes allocated: 748225848 Deviation T9961(normal) bytes allocated: -3.1 % I'm not sure if it's just the test-case being broken, or there's something real regression between 7.10 and HEAD... However, I don't have time to investigate this. Cheers, hvr

2 1