February 2015 - ghc-devs

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

10 Feb '15

Hi *, Welcome! This is the first GHC Weekly news of February 2015. You might be wondering what happened to the last one. Well, your author was just in New York for the past week attending [http://www.composeconference.org Compose Conference], making friends and talking a lot about Haskell (luckily we missed a snow storm that may have messed it up quite badly!) The conference was great. I got to have some interesting discussions about GHC and Haskell with many friendly faces from all around at an incredibly well run conference with a stellar set of people. Many thanks to NY Haskell (organizing), Spotify (hosting space), and to all the speakers for a wonderful time. (And of course, your editor would like to thank his employer Well-Typed for sending him!) But now, since your author has returned, GHC HQ met back up this week for some discussion, with some regularly scheduled topics. For the most part it was a short meeting this week - our goals are pretty well identified: - GHC HQ and the Core Libraries Committee have posted a survey on the future of the 7.10 prelude and the FTP/BBP discussion. The deadline is February 20th, so please vote if the discussion is of interest to you. Simon Peyton-Jones and Simon Marlow will be making the final decision. https://www.haskell.org/pipermail/haskell-cafe/2015-February/118095.html - It's likely GHC HQ will do a third 7.10.1 Release Candidate at the very end of February after the votes are included. We missed some patches in RC2 (such as Phab:D347) and incorporated even more bugfixes, so this is worth a test drive by users. - For the most part, things for 7.10 have been going very smoothly other than the debates and a few bugs trickling in - there has not been much ticket activity the past two weeks, so things feel pretty good right now. Austin will mostly be focused on shipping 7.10 and keeping the normal review/patch/triaging cycles going until it's done. We're on track to fix all the major bugs we've assigned (see milestone:7.10.1). Since my last post, we've also had other random assorted chatter on the mailing lists by the dev team: - In light of a recent large bug in GHC which can be used to derive `unsafeCoerce`, GHC HQ '''has decided to push back the 7.10 release a bit longer to about March''', in order to fix this bug and ferret out the little fallout afterwords. It turns out this isn't a simple bug to fix, but luckily a fix is being worked on already. https://www.haskell.org/pipermail/ghc-devs/2015-January/008189.html - Luckily, Iavor has started work on fixing this nasty bug, and had a few questions for the list: https://www.haskell.org/pipermail/ghc-devs/2015-February/008269.html - Iavor Diatchki has raised a new topic about a simpler OverloadedRecordsField proposal. Adam swooped in to address some points about the design. https://www.haskell.org/pipermail/ghc-devs/2015-January/008183.html - Herbert Valerio Riedel posted about a huge (76x) regression between GHC 7.11 and GHC 7.10, but strangely nobody has picked up as to why this is the case yet! https://www.haskell.org/pipermail/ghc-devs/2015-January/008207.html - David Feuer has a question: why is `undefined` so special? In particular, it seems as if `undefined` can be specially used as a value with a type of kind `#` as well as `*`. It turns out GHC has a special notion of subkinding, and `undefined` has a type more special than meets the eye which allows this, as Adam Gundry replied. https://www.haskell.org/pipermail/ghc-devs/2015-February/008222.html - Merijn Verstraaten has started up a discussion about a new proposal of his, ValidateMonoLiterals. The proposal revolves around the idea of using GHC to enforce compile-time constraints on monomorphic literals, whose type may have invariants enforced on them. While this is doable with Template Haskell, Merijn would like to see something inside GHC instead. https://www.haskell.org/pipermail/ghc-devs/2015-February/008239.html - David Feuer asked: can we merge `FlexibleContexts` with `FlexibleInstances`? The proposal seems to be relatively undiscussed at the moment with a neutral future, but perhaps someone would like to chime in on this minor issue. https://www.haskell.org/pipermail/ghc-devs/2015-February/008245.html - Greg Weber opened up a discussion about 'Restricted Template Haskell', which would hopefully make it easier for users to see what a TH computation is actually doing. It turns out - as noted by Simon - that Typed Template Haskell is perhaps closer to what Greg wants. The proposal and discussion then resulted in us realising that the typed TH documentation is rather poor! Hopefully Greg or someone can swing in to improve things. https://www.haskell.org/pipermail/ghc-devs/2015-February/008232.html Closed tickets the past two weeks include: #10028, #10040, #10031, #9935, #9928, #2615, #10048, #10057, #10054, #10060, #10017, #10038, #9937, #8796, #10030, #9988, #10066, #7425, #7424, #7434, #10041, #2917, #4834, #10004, #10050, #10020, #10036, #9213, and #10047. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

Trouble pushing changes?
by Iavor Diatchki 10 Feb '15

10 Feb '15

Hello, Today I made some more progress with the implementation of `Typebable with kinds`. In the process, I had to update one line in the `deepseq` package, because it has code to `rnf` `TypeReps`, which now have an extra field. I made a separate branch in `deep-seq` where I was going to push the change, but when I try to do so I get the following error: git push -u origin typeable-with-kinds:typeable-with-kinds Counting objects: 30, done. Delta compression using up to 8 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (4/4), 377 bytes | 0 bytes/s, done. Total 4 (delta 2), reused 0 (delta 0) remote: W refs/heads/typeable-with-kinds packages/deepseq diatchki DENIED by refs/.* remote: error: hook declined to update refs/heads/typeable-with-kinds To ssh://git@git.haskell.org/packages/deepseq.git ! [remote rejected] typeable-with-kinds -> typeable-with-kinds (hook declined) error: failed to push some refs to 'ssh:// git(a)git.haskell.org/packages/deepseq.git' Any ideas what that's about? Perhaps, it is simply that I don't have permission to push to `deep-seq`? -Iavor

2 4

RE: [Haskell-cafe] GHC 7.10 Prelude: we need your opinion
by Simon Peyton Jones 10 Feb '15

10 Feb '15

| What were the objections? Especially the principle ones? Please read the info pages, which set out the arguments quite carefully. Also, I spammed several email lists to ensure broad coverage, but it'd be best to debate on the libraries(a)haskell.org, rather than reply-to-all; that's what it's for. (Which I failed to send the announcement to! I'll fix that.) Simon | -----Original Message----- | From: Miguel Mitrofanov [mailto:miguelimo38@yandex.ru] | Sent: 10 February 2015 15:59 | To: Simon Peyton Jones; haskell(a)haskell.org; Haskell Cafe (haskell- | cafe(a)haskell.org) GHC users; ghc-devs(a)haskell.org | Subject: Re: [Haskell-cafe] GHC 7.10 Prelude: we need your opinion | | What were the objections? Especially the principle ones? | | 10.02.2015, 18:51, "Simon Peyton Jones" <simonpj(a)microsoft.com>: | > Haskell Friends | > | > This email asks for your help in deciding how to proceed with some | Prelude changes in GHC 7.10. Please read on, but all the info is also | at the survey link, here: http://goo.gl/forms/XP1W2JdfpX. Deadline | is 21 Feb. | > | > The Core Libraries Committee (CLC) is responsible for developing the | core libraries that ship with GHC. This is an important but | painstaking task, and we owe the CLC a big vote of thanks for taking | it on. | > | > For over a year the CLC has been working on integrating the Foldable | and Traversable classes (shipped in base in GHC 7.8) into the core | libraries, and into the Prelude in particular. Detailed planning for | GHC 7.10 started in the autumn of 2014, and the CLC went ahead with | this integration. | > | > Then we had a failure of communication. As these changes affect the | Prelude, which is in scope for all users of Haskell, these changes | should be held to a higher bar than the regular libraries@ review | process. However, the Foldable/Traversable changes were not | particularly well signposted. Many people have only recently woken up | to them, and some have objected (both in principle and detail). | > | > This is an extremely unfortunate situation. On the one hand we are | at RC2 for GHC 7.10, so library authors have invested effort in | updating their libraries to the new Prelude. On the other, altering | the Prelude is in effect altering the language, something we take | pretty seriously. We should have had this debate back in 2014, but | here we are, and it is unproductive to argue about whose fault it is. | We all share responsibility. | > | > We need to decide what to do now. A small group of us met by Skype | and we've decided to do this: | > | > · Push back GHC 7.10's release by at least a month, to late | March. This delay also gives us breathing space to address an | unrelated show-stopping bug, Trac #9858. | > | > · Invite input from the Haskell community on which of two | approaches to adopt (this survey). The main questions revolve around | impact on the Haskell ecosystem (commercial applications, teaching, | libraries, etc etc), so we want to ask your opinion rather than guess | it. | > | > · Ask Simon Marlow and Simon Peyton Jones to decide which | approach to follow for GHC 7.10. | > | > Wiki pages have been created summarizing these two primary | alternatives, including many more points and counter-points and | technical details: | > | > · Overall summary: | https://ghc.haskell.org/trac/ghc/wiki/Prelude710 | > | > · Details of Plan List: | https://ghc.haskell.org/trac/ghc/wiki/Prelude710/List | > | > · Details of Plan FTP: | https://ghc.haskell.org/trac/ghc/wiki/Prelude710/FTP | > | > This survey invites your input on which plan we should follow. Would | you please | > | > · Read the details of the alternative plans on the three | wiki pages above | > | > · Add your response to the survey | > | > Please do read the background. Well-informed responses will | help. Thank you! | > | > DEADLINE: 21 February 2015 | > | > Simon PJ | > | > , | > | > _______________________________________________ | > Haskell-Cafe mailing list | > Haskell-Cafe(a)haskell.org | > http://www.haskell.org/mailman/listinfo/haskell-cafe

1 0

GHC 7.10 Prelude: we need your opinion
by Simon Peyton Jones 10 Feb '15

10 Feb '15

Haskell Friends This email asks for your help in deciding how to proceed with some Prelude changes in GHC 7.10. Please read on, but all the info is also at the survey link, here: http://goo.gl/forms/XP1W2JdfpX. Deadline is 21 Feb. The Core Libraries Committee (CLC) is responsible for developing the core libraries that ship with GHC. This is an important but painstaking task, and we owe the CLC a big vote of thanks for taking it on. For over a year the CLC has been working on integrating the Foldable and Traversable classes (shipped in base in GHC 7.8) into the core libraries, and into the Prelude in particular. Detailed planning for GHC 7.10 started in the autumn of 2014, and the CLC went ahead with this integration. Then we had a failure of communication. As these changes affect the Prelude, which is in scope for all users of Haskell, these changes should be held to a higher bar than the regular libraries@ review process. However, the Foldable/Traversable changes were not particularly well signposted. Many people have only recently woken up to them, and some have objected (both in principle and detail). This is an extremely unfortunate situation. On the one hand we are at RC2 for GHC 7.10, so library authors have invested effort in updating their libraries to the new Prelude. On the other, altering the Prelude is in effect altering the language, something we take pretty seriously. We should have had this debate back in 2014, but here we are, and it is unproductive to argue about whose fault it is. We all share responsibility. We need to decide what to do now. A small group of us met by Skype and we've decided to do this: · Push back GHC 7.10's release by at least a month, to late March. This delay also gives us breathing space to address an unrelated show-stopping bug, Trac #9858. · Invite input from the Haskell community on which of two approaches to adopt (this survey<http://goo.gl/forms/XP1W2JdfpX>). The main questions revolve around impact on the Haskell ecosystem (commercial applications, teaching, libraries, etc etc), so we want to ask your opinion rather than guess it. · Ask Simon Marlow and Simon Peyton Jones to decide which approach to follow for GHC 7.10. Wiki pages have been created summarizing these two primary alternatives, including many more points and counter-points and technical details: · Overall summary: https://ghc.haskell.org/trac/ghc/wiki/Prelude710<https://www.google.com/url?q=https%3A%2F%2Fghc.haskell.org%2Ftrac%2Fghc%2Fw…> · Details of Plan List: https://ghc.haskell.org/trac/ghc/wiki/Prelude710/List<https://www.google.com/url?q=https%3A%2F%2Fghc.haskell.org%2Ftrac%2Fghc%2Fw…> · Details of Plan FTP: https://ghc.haskell.org/trac/ghc/wiki/Prelude710/FTP<https://www.google.com/url?q=https%3A%2F%2Fghc.haskell.org%2Ftrac%2Fghc%2Fw…> This survey invites your input on which plan we should follow. Would you please · Read the details of the alternative plans on the three wiki pages above · Add your response to the survey<http://goo.gl/forms/XP1W2JdfpX> Please do read the background. Well-informed responses will help. Thank you! DEADLINE: 21 February 2015 Simon PJ

1 0

LLVM
by Simon Peyton Jones 10 Feb '15

10 Feb '15

I'm getting this on Linux (Ubuntu). How do I get a newer version of llvm? Simon <no location info>: You are using an old version of LLVM that isn't supported anymore! We will try though... /usr/bin/opt: /tmp/ghc451_0/ghc451_1.ll:7:6: error: expected type !0 = !{!"top", i8* null} ^

2 1

Re: Proposal: ValidateMonoLiterals - Initial bikeshed discussion
by Dan Doel 10 Feb '15

10 Feb '15

Assuming a separate syntax, I believe that the criterion would be as simple as ensuring that no ValidateFoo constraints are left outstanding. The syntax would add the relevant validate call, and type variables involved in a ValidateFoo constraint would not be generalizable, and would have to be defaulted or inferred from elsewhere, similar to the monomorphism restriction. I'm not sure how difficult that would be to implement. I'm not terribly gung ho on this, though. It feels very ad hoc. Making validation vs. non-validation syntactic rather than just based on polymorphism seems somewhat less so, though; so I'd prefer that direction. Finding unused syntax is always a problem, of course. On Fri, Feb 6, 2015 at 11:38 AM, Ryan Trinkle <ryan.trinkle(a)gmail.com> wrote: > My greatest concern here would be that, as an application is maintained, a > literal might go from monomorphic to polymorphic, or vice versa, without > anybody noticing. It sounds like this could result in a value silently > becoming partial, which would be a big problem for application stability; > in the opposite case - a partial value becoming a compile-time error - I am > somewhat less concerned, but it could still be confusing and disruptive. > > I would prefer that there be some syntactic indication that I want my > literal to be checked at compile time. This syntax could also add whatever > monomorphism requirement is needed, and then it would become a compile-time > error for the value to become polymorphic. I don't know nearly enough > about the type system to know whether this is possible. > > Also, it seems to me that it might not be so clean as "monomorphic" versus > "polymorphic". For example, suppose I have this: > > newtype PostgresTableName s = PostgresTableName String > > where 's' is a phantom type representing the DB schema that the name lives > in. The validation function is independent of the schema - it simply fails > if there are illegal characters in the name, or if the name is too long. > So, ideally, ("foo\0bar" :: forall s. PostgresTableName s) would fail at > compile time, despite being polymorphic. > > > Ryan > > On Fri, Feb 6, 2015 at 11:16 AM, Merijn Verstraaten < > merijn(a)inconsistent.nl> wrote: > >> Ryan, >> >> Unfortunately, yes, you are understanding that correctly. >> >> The reason I qualified it with "monomorphic only" is that, I want to >> avoid breakage that would render the extension practically unusable in real >> code. >> >> Let's say I right now have: >> >> foo :: Num a => [a] -> [a] >> foo = map (+1) >> >> I have two options 1) we compile this as currently using fromIntegral and >> it WILL break for Even or 2) we reject any polymorphic use of literals like >> this. Given the amount of numerical code relying on the polymorphism of >> Num, I think the option of not being able to compile Num polymorphic code >> is completely out of the question. Almost no application would work. >> >> I would advocate in favour of not requiring an IsList/IsString instance >> for the validation class, this would allow you to write a conversion that >> ONLY converts literals in a validated way and will never successfully >> convert literals without the extension, since with the extension disabled >> GHC would try to use the fromList/fromString from the IsString/IsList >> classes which do not exist. >> >> Unfortunately, given how deeply fromIntegral is tied to the Num class I >> don't see any way to achieve the same for Num. The only option would be to >> not make Even an instance of Num, that way the same trick as above could >> work. Removing fromIntegral from Num is obviously not going to happen and >> without doing that I don't see how we could prevent someone using >> fromIntegral manually to convert to Even in a way that won't break Num >> polymorphic functions. If you have any ideas on how to tackle this, I'm all >> open to hearing them! >> >> I agree with you that this is ugly, but I console myself with the thought >> that being able to check all monomorphic literals is already a drastic >> improvement over the current state. And in the case of lists and strings we >> could actually ensure that things work well, since almost no one writes >> "IsString polymorphic" code. >> >> Cheers, >> Merijn >> >> > On 6 Feb 2015, at 16:59, Ryan Trinkle <ryan.trinkle(a)gmail.com> wrote: >> > >> > I think the idea of compile-time validation for overloaded literals is >> fantastic, and doing it with nicer syntax than quasiquoting would really >> improve things. However, I'm a bit confused about specifically how the >> requirement that it be monomorphic will play into this. For example, if I >> have: >> > >> > x = 1 >> > >> > Presumably this will compile, and give a run-time error if I ever >> instantiate its type to Even. However, if I have: >> > >> > x :: Even >> > x = 1 >> > >> > it will fail to compile? Furthermore, if I have the former, and type >> inference determines that its type is Even, it sounds like that will also >> fail to compile, but if type inference determines that its type is forall >> a. Nat a => a, then it will successfully compile and then fail at runtime. >> > >> > Am I understanding this correctly? >> > >> > >> > Ryan >> > >> > On Fri, Feb 6, 2015 at 8:55 AM, Erik Hesselink <hesselink(a)gmail.com> >> wrote: >> > On Fri, Feb 6, 2015 at 2:49 PM, Dominique Devriese >> > <dominique.devriese(a)cs.kuleuven.be> wrote: >> > > Agreed. For the idea to scale, good support for type-level >> > > programming with Integers/Strings/... is essential. Something else >> > > that would be useful is an unsatisfiable primitive constraint >> > > constructor `UnsatisfiableConstraint :: String -> Constraint` that can >> > > be used to generate custom error messages. Then one could write >> > > something like >> > > >> > > type family MustBeTrue (t :: Bool) (error :: String) :: Constraint >> > > type family MustBeTrue True _ = () >> > > type family MustBeTrue False error = UnsatisfiableConstraint error >> > > >> > > type family MustBeEven (n :: Nat) :: Constraint >> > > type family MustBeEven n = MustBeTrue (IsEven n) ("Error in Even >> > > literal :'" ++ show n ++ "' is not even!") >> > > >> > > instance (KnownNat n, MustBeEven n) => HasIntegerLiteral Even n >> where ... >> > >> > Note that there is a trick to fake this with current GHC: you can >> > write an equality constraint that is false, involving the type level >> > string: >> > >> > > type family MustBeTrue False error = (() ~ error) >> > >> > Erik >> > _______________________________________________ >> > Glasgow-haskell-users mailing list >> > Glasgow-haskell-users(a)haskell.org >> > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users(a)haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> >> > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > >

3 4

Question about implementing `Typeable` (with kinds)
by Iavor Diatchki 09 Feb '15

09 Feb '15

Hello, I started adding custom solving for `Typeable` constraints, to work around the problem where kind parameters were missing from the representation of types. The idea is as follows: 1. Add a new filed to `TypeRep` that remembers _kind_ parameters: TypeRep Fingerprint TyCon [TypeRep]{-kinds-} [TypeRep]{-types-} 2. Modify the constraint solver, to solve constraints like this: - Kind-polymorphic type constructors don't get `Typeable` instances on their own - GHC can solve `Typeable` constraints on _*concrete uses*_ of polymorphic type constructors. More precisely, GHC can solve constraints of the form `Typeable k (TC @ ks)`, as long as: (1) `k` is not a forall kind, (2) the `ks` are all concrete kinds (i.e., they have no free kind variables). This all seems fairly straight-forward, but I got stuck on the actual implementation, in particular: *what `EvTerm` should I use when discharging a `Typeable` constraint?* I can create a an `HsSyn` value for the required method (i.e., a function of type `Proxy# t -> TypeRep`). I can also cast this into a `Typeable` dictionary value. The issue is that I am left with an `HsSyn` expression, and not an `EvTerm`. So is there a way to treat an arbitrary expression as an `EvTerm`? In the implementation of the type-lits, I just added custom evidence, but this does not scale well (also, in that case the evidence is just a simple value, while here it is a bit more complex). Suggestions would be most appreciated! -Iavor

4 5

Re: Proposal: ValidateMonoLiterals - Initial bikeshed discussion
by Gershom B 09 Feb '15

09 Feb '15

I recall having some discussions with Mathieu Boespflug regarding how the static pointers work could be of use here. (And also Richard Eisenberg?) In particular, we want to demand a special property of our validation functions -- that they can safely be used at compile-time without necessarily "linking in the world" and invoking the whole of template haskell. A function that is "static" should in a sense have this sort of property? And so requiring that our validation functions be static seems like a useful thing from an implementation standpoint. Static semantics might also help "force the thunk" on what the correct relationship to polymorphism is. I guess the remaining question is then where to add them. I suppose we could stick them with special semantics on Num and IsString or the like and do it by magic? Alternately we could maybe have a whole class of "compile-time static functions" that we just explicitly use, and all have the property that they have type "a -> a" for some concrete "a", and that the value they are applied to is static. These functions are then applied at compile time, and forced to whnf. If they toss an error it is a compile error, otherwise they are not present in the generated code. There are other design variations possible, but that one feels pretty neat to me, if feasible. So then I could write foo :: Even foo = even 6 for example, and get errors at compile-time. On top of this we could add a special way to augment Num, IsString, etc with such methods to yield the desired: foo :: Even foo = 6 -gershom

3 2

ghc-7.8 in Fedora Rawhide
by Jens Petersen 07 Feb '15

07 Feb '15

The Fedora Haskell SIG is pleased to announce the arrival of GHC 7.8 in the Fedora 22 Rawhide development tree. - the GHC version is 7.8.4: we are no longer following haskell-platform strictly, - over 120 Haskell packages have been updated to their latest versions, including pandoc-1.13.2. There are currently still a few issues in Rawhide: - a few packages have not yet been rebuilt/updated with ghc-7.8.4: - errors: bustle, ghc-ForSyde, ghc-type-level, ghc-parameterized-data - new deps needed: hledger, Agda, leksah, cab - also on ARMv7 the RTS seems to have some strange problems leading to crashes which is under investagation: no idris build on armv7: < https://ghc.haskell.org/trac/ghc/ticket/10029>. Thanks, Jens

1 0

Proposal: ValidateMonoLiterals - Initial bikeshed discussion
by Merijn Verstraaten 06 Feb '15

06 Feb '15

I've been repeatedly running into problems with overloaded literals and partial conversion functions, so I wrote up an initial proposal (https://ghc.haskell.org/trac/ghc/wiki/ValidateMonoLiterals) and I'd like to commence with the bikeshedding and hearing other opinions :) Cheers, Merijn

6 10