- ghc-devs - Haskell.org

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(a)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

Behavior change of Data.Char
by Kazu Yamamoto 19 Feb '15

19 Feb '15

Hi, 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 isSymbol (chr 182) True False isPunctuation (chr 182) Fase True Is this intentional? I noticed this because I received a bug report: https://github.com/kazu-yamamoto/word8/issues/3 As you can see, 167 also behaves differently. --Kazu

5 5

RE: Resolving Windows 64-bit linker issues
by Tamar Christina 18 Feb '15

18 Feb '15

Hi Simon, We do have a page on Trac with the members: https://ghc.haskell.org/trac/ghc/wiki/WindowsTaskForce We could add the extra information there. Regards, Tamar ------------------------------ From: Simon Peyton Jones <simonpj(a)microsoft.com> Sent: ‎17/‎02/‎2015 10:18 To: Darren Grant <dedgrant(a)gmail.com>; Mikolaj Konarski <mikolaj(a)well-typed.com> Cc: Phyx <lonetiger(a)gmail.com>; Roman Kuznetsov <kuznero(a)gmail.com>; ghc-devs(a)haskell.org; David Macek <david.macek.0(a)gmail.com>; kyrab <kyrab(a)mail.ru>; Gintautas Miliauskas <gintautas(a)miliauskas.lt>; Martin Foster <martin.e.foster(a)gmail.com> Subject: RE: Resolving Windows 64-bit linker issues One really helpful thing would be to · make a wiki home page for the Windows Task Force · list who is on it · list the main tasks “in flight” and what their status is · any other plans Anything to broaden visibility of the WTF, and encourage others to join in. Communication is all in an open-source context! Thanks for working on Windows… it’s a very popular platform, and needs your love! Simon *From:* Darren Grant [mailto:dedgrant@gmail.com] *Sent:* 17 February 2015 05:03 *To:* Mikolaj Konarski *Cc:* Phyx; Roman Kuznetsov; ghc-devs(a)haskell.org; Simon Peyton Jones; David Macek; kyrab; Gintautas Miliauskas; Martin Foster *Subject:* Re: Resolving Windows 64-bit linker issues To expand on that (let's see if I can do this without accidentally sending again, oops!): Roman, I will get in touch with you on a separate email thread to see if we can find an optimal way to coordinate, something that satisfies our schedules and needs. Others please feel free to bug me any time by email ( dedgrant(a)gmail.com) or on freenode #ghc as dedgrant, PST hours. In the meantime I'll be auditing some of the related backlogged tickets on trac. If there's something I can do to help further the goal of a Windows Task Force page, please let me know. Pleased to meet everyone! Cheers, Darren On Mon, Feb 16, 2015 at 8:48 PM, Darren Grant <dedgrant(a)gmail.com> wrote: Thank you kindly for the great introduction. I hope I can be helpful here. On Feb 16, 2015 7:47 AM, "Mikolaj Konarski" <mikolaj(a)well-typed.com> wrote: Resending, since Roman's and Kyril's email addresses were mangled/missing. On Mon, Feb 16, 2015 at 3:43 PM, Simon Peyton Jones <simonpj(a)microsoft.com> wrote: > Darren > > > > Excellent! We have a Windows Task Force, consisting roughly of the folk in > cc. So they would be the first group to ask. > > > > (I think it would be very helpful to have a Windows Task Force home page, so > that it’s easier to find the group.) > > > > thanks for helping with Windows. > > > > Simon > > > > From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Darren > Grant > Sent: 15 February 2015 07:36 > To: ghc-devs(a)haskell.org > Subject: Resolving Windows 64-bit linker issues > > > > Hi all, > > > > I notice there are a series of related long-standing issues subject to > particular cygwin64 quirks, and I'd like to offer time to help resolve these > if possible > > At this point I've had some exposure to the GHC build process (7.8.3), and > have poked around the GHC linker to gain some low level insight. > > > > Would anyone be available to fill me in on the current state of affairs with > mingw64 GHCi linking? For instance, is there ongoing work, or perhaps a > preferred direction but no available developer bandwidth to proceed? > > > > Thank you. > > > > Cheers, > > Darren > >

6 9