- ghc-devs - Haskell.org

stranal/sigs/UnsatFun
by Richard Eisenberg 30 Nov '15

30 Nov '15

Hi devs, On my kind=type branch (D808), I have this test failure for stranal/sigs/UnsatFun: ==================== Strictness signatures ==================== UnsatFun.$trModule: m UnsatFun.f: <B,1*U(U)><B,A>b -UnsatFun.g: <B,1*U(U)>b -UnsatFun.g': <L,1*U(U)> +UnsatFun.g: <L,U(U)> +UnsatFun.g': <L,U(U)> UnsatFun.g3: <L,U(U)>m -UnsatFun.h: <C(S),1*C1(U(U))> -UnsatFun.h2: <S,1*U><L,1*C1(U(U))> -UnsatFun.h3: <C(S),1*C1(U)>m +UnsatFun.h: <S,1*U> +UnsatFun.h2: <S,1*U><L,1*U> +UnsatFun.h3: <S,1*U>m *** unexpected failure for UnsatFun(optasm) I haven't any clue what this means. Is it bad? Is it good? Any pointers? Thanks! Richard

3 6

What is causing the "Unrecognized field abi" warning?
by Sven Panne 30 Nov '15

30 Nov '15

This shows up in more recent builds of my packages on Travis CI, e.g. https://travis-ci.org/haskell-opengl/OpenGL/jobs/93814917#L296, but I don't have a clue what's causing it (GHC? cabal? Something else?), if I should ignore it or if I should somehow act on that. :-/ My gut feeling is that it's GHC, but I might be wrong... Cheers, S.

2 2

Remove deprecated quasiquote syntax
by Matthew Pickering 29 Nov '15

29 Nov '15

The [$qq| quasiquote syntax has been deprecated since around 2010. Is there any objection to removing the backwards compatibility now? I counted 216 uses of it on hackage in a handful of packages, some in comments. http://lpaste.net/145938 Here is the commit which deprecated it - https://github.com/ghc/ghc/commit/9ba922ee06b048774d7a82964867ff768a78126e Matt

3 3

Should (~) be homogeneous or heterogeneous?
by Richard Eisenberg 27 Nov '15

27 Nov '15

Hi devs, I'm desperately working toward getting kind equalities in before the feature freeze. It's coming along nicely. But I have a user-facing issue to work out. * Should (~), as written in user code, require the kinds of its arguments to be equal? Another way of asking the same question is: Should the kind of (~) be 1. forall k. k -> k -> Constraint (HEAD) 2. forall k1 k2. k1 -> k2 -> Constraint (my branch, at the moment) Choice #2 is strictly more powerful and cannot be expressed in terms of #1. But #1 is perhaps more intuitive for programmers, who might expect inference to conclude that the two kinds are the same. Here is an example of where the difference matters: > data KProxy k = KP > class kproxy ~ 'KP => C (kproxy :: KProxy k) We can see that the kind of the type variable kproxy should be (KProxy k). But we still have to infer the kind of the occurrence of 'KP on the left. HEAD sees the kind of kproxy and infers that 'KP should have kind (KProxy k). My branch, on the other hand, doesn't have any reason to constrain the kind of 'KP, and so it gets (KProxy Any), which quickly causes trouble. The fix is easy: add a kind signature. I see two ways forward, corresponding to the choices for the kind of (~) above: 1. Make (~) homogeneous and introduce a new constraint (~~) that is like (~) but heterogeneous. We resign ourselves to explaining the technical, subtle difference between (~) and (~~) into perpetuity. 2. Make (~) heterogeneous. Some people will have to add kind annotations to their code to port from GHC 7.10 to GHC 8.0. But these kind annotations will be fully backward-compatible, and won't require CPP, or warnings, or any other bother. We may have to explain why kind inference around (~) is weaker than it was before. I'm (clearly?) leaning toward #2. But I'd like feedback. Thoughts? Thanks! Richard

4 6

Reproducible builds using GHC
by Joachim Breitner 27 Nov '15

27 Nov '15

Hi Bartosz, you might be aware of the reproducible builds project (https://reproducible-builds.org/) which tries to make as much software as possible to build reproducibly, i.e. bitwise identical output files. I have done a few minor things in that direction myself and therefore got invited to the “Reproducibly World Summit” next week in Athens. But by now, you have worked much harder on the problem than I ever have, and so you have a much better overview of the remaining issues. Would you mind posting an update on your work on #4012, about what remains to be done, whether you think that the remaining problems are solved (and just need doing) or whether there are issues without a known solution so far? I know that your focus right now is reproducible interface files, but can you say something about how far away reproducible binary files are, once the interface files are reproducible? Are the causes of non- determinism in principle the same in either case, or are there unique problems when it comes to object files? Are there areas of work where you could need some extra help? Thanks for your input, 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

1 0

RE: D1428: Rework treatment of wildcards
by Simon Peyton Jones 26 Nov '15

26 Nov '15

Ben So that you know, the state of play is: * wip/spj-wildcard-refactor is fully up to speed with HEAD * It validates except for perf/compiler/T3064 (8% loss) * It does need a decent commit message I'd really like this in 8.0: - It's a big patch, so not having it will lead to lots of tiresome cross-branch porting - It does fix things in the wildcard story Of these the former is the more important. The only think holding me up is that I really don't understand the perf regression. It seems to be in the simplifier, which I have not touched! Working on it. But in the worst case I can commit and open a ticket for the perf regression Simon | -----Original Message----- | From: noreply(a)phabricator.haskell.org | [mailto:noreply@phabricator.haskell.org] | Sent: 26 November 2015 14:40 | To: Simon Peyton Jones <simonpj(a)microsoft.com> | Subject: [Differential] [Requested Changes To] D1428: Rework treatment | of wildcards | | bgamari requested changes to this revision. | bgamari added a comment. | This revision now requires changes to proceed. | | Requesting changes to bump this out of the review queue. | | | REPOSITORY | rGHC Glasgow Haskell Compiler | | REVISION DETAIL | https://phabricator.haskell.org/D1428 | | EMAIL PREFERENCES | https://phabricator.haskell.org/settings/panel/emailpreferences/ | | To: austin, hvr, goldfire, simonpj, bgamari | Cc: jstolarek, alanz, goldfire, thomie, mpickering, simonpj

2 1

Re: [GHC] #11028: Refactor ConDecl
by Alan & Kim Zimmerman 25 Nov '15

25 Nov '15

As I wrote that I came to the same conclusion, but decided to leave the rest in case. On Thu, Nov 26, 2015 at 12:25 AM, GHC <ghc-devs(a)haskell.org> wrote: > #11028: Refactor ConDecl > -------------------------------------+------------------------------------- > Reporter: simonpj | Owner: alanz > Type: bug | Status: new > Priority: normal | Milestone: > Component: Compiler | Version: 7.10.2 > Resolution: | Keywords: > Operating System: Unknown/Multiple | Architecture: > | Unknown/Multiple > Type of failure: None/Unknown | Test Case: > Blocked By: | Blocking: > Related Tickets: | Differential Rev(s): > Wiki Page: | > -------------------------------------+------------------------------------- > > Comment (by simonpj): > > > Alternatively, everything except the `rnLHsType` in `rnConResult` can > move to the type checking. > > That sounds exactly right. `Note [Sorting out the result type]` in > `RdrHsSyn` seems entirely redundant with the new `ConDeclGADT` form. > > -- > Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11028#comment:25> > GHC <http://www.haskell.org/ghc/> > The Glasgow Haskell Compiler >

1 0

Re: [GHC] #11028: Refactor ConDecl
by Alan & Kim Zimmerman 25 Nov '15

25 Nov '15

I just pushed to wip/T11028 It is very much a work in progress, working through to sort out the compiler errors, in the simplest way at the moment. On Wed, Nov 25, 2015 at 3:06 PM, GHC <ghc-devs(a)haskell.org> wrote: > #11028: Refactor ConDecl > -------------------------------------+------------------------------------- > Reporter: simonpj | Owner: alanz > Type: bug | Status: new > Priority: normal | Milestone: > Component: Compiler | Version: 7.10.2 > Resolution: | Keywords: > Operating System: Unknown/Multiple | Architecture: > | Unknown/Multiple > Type of failure: None/Unknown | Test Case: > Blocked By: | Blocking: > Related Tickets: | Differential Rev(s): > Wiki Page: | > -------------------------------------+------------------------------------- > > Comment (by simonpj): > > Yes, because of the possibility of `HsRecTy`, you can't use `tcHsSigType`. > So something like what you propose looks good. > > Ca you make a branch and push what you have so that I can see? > > -- > Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11028#comment:19> > GHC <http://www.haskell.org/ghc/> > The Glasgow Haskell Compiler >

1 0

Monad fail errors
by Simon Peyton Jones 24 Nov '15

24 Nov '15

Herbert In tests/monadfail/MonadFailErrors.stderr I see MonadFailErrors.hs:59:5: error: No instance for (MonadFail Identity) arising from a do statement with the failable pattern ‘Newtype x’ In a stmt of a 'do' block: Newtype x <- undefined In the expression: do { Newtype x <- undefined; undefined } In an equation for ‘newtypeMatch’: newtypeMatch = do { Newtype x <- undefined; undefined } MonadFailErrors.hs:67:5: error: No instance for (MonadFail Identity) arising from a do statement with the failable pattern ‘Data x’ In a stmt of a 'do' block: Data x <- undefined In the expression: do { Data x <- undefined; undefined } In an equation for ‘singleConMatch’: singleConMatch = do { Data x <- undefined; undefined } But ‘Newtype’ and ‘Data’ are single constructor types and hence cannot fail. So why are these errors happening? I’m tiding up your implementation (deleting code!) and accidentally fixed this. So I wanted to check that it is indeed wrong as-is. Simon

1 0

RE: [GHC] #11019: ApiAnnotations: Make all RdrName occurences Located
by Simon Peyton Jones 23 Nov '15

23 Nov '15

The commit is a one-line change to IEThingAll, which says: -- See Note [Located RdrNames] in HsExpr But HsExpr does not contain such a Note. Did you omit something? Simon From: Alan & Kim Zimmerman [mailto:alan.zimm@gmail.com] Sent: 23 November 2015 13:40 To: Simon Peyton Jones <simonpj(a)microsoft.com> Subject: Re: [GHC] #11019: ApiAnnotations: Make all RdrName occurences Located Done, see https://phabricator.haskell.org/rGHC7c9a04d6eda5495f150a1140e6d26fc64e319b7e On Mon, Nov 23, 2015 at 12:13 PM, Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: Alan | ApiAnnotations: Make all RdrName occurences Located There is a principle here: that every RdrName occurrence is located. Is this principle articulated in a Note anywhere? I wish it was! (Including an explanation of why.) Otherwise you risk someone removing the change in a few years time. When I built HsSyn originally I reasoned that data HsExpr = ...| HsVar RdrName was better than data HsExpr = ... | HsVar (Located RdrName0 because the location on the RdrName is identical to that on the LHsExpr, so it's redundant. But you think it is non-redundant. I'm sure you are right (although I don't know why), but it would be a real help to document the invariant and the reasoning in the code somewhere. Are there any other principles that the code embodies? Thanks Simon | -----Original Message----- | From: ghc-tickets [mailto:ghc-tickets-bounces@haskell.org<mailto:ghc-tickets-bounces@haskell.org>] On Behalf | Of GHC | Sent: 22 November 2015 23:11 | Cc: ghc-tickets(a)haskell.org<mailto:ghc-tickets@haskell.org> | Subject: Re: [GHC] #11019: ApiAnnotations: Make all RdrName occurences | Located | | #11019: ApiAnnotations: Make all RdrName occurences Located | -------------------------------------+-------------------------------- | -- | -------------------------------------+--- | Reporter: alanz | Owner: alanz | Type: bug | Status: new | Priority: normal | Milestone: 8.0.1 | Component: Compiler | Version: 7.10.2 | Resolution: | Keywords: | | ApiAnnotations | Operating System: Unknown/Multiple | Architecture: | | Unknown/Multiple | Type of failure: None/Unknown | Test Case: | Blocked By: | Blocking: | Related Tickets: | Differential Rev(s): | Phab:1512 | Wiki Page: | | -------------------------------------+-------------------------------- | -- | -------------------------------------+--- | | Comment (by Ben Gamari <ben@…>): | | In [changeset:"3df9563e590bbfbfe1bc9171a0e8fc93ceef690d/ghc" | 3df9563e/ghc]: | {{{ | #!CommitTicketReference repository="ghc" | revision="3df9563e590bbfbfe1bc9171a0e8fc93ceef690d" | ApiAnnotations: Make all RdrName occurences Located | | At the moment the API Annotations can only be used on the | ParsedSource, as there are changes made to the RenamedSource that | prevent it from being used to round trip source code. | | It is possible to build a map from every Located Name in the | RenamedSource from its location to the Name, which can then be used | when resolved names are required when changing the ParsedSource. | | However, there are instances where the identifier is not located, | specifically | | (GHC.VarPat name) | (GHC.HsVar name) | (GHC.UserTyVar name) | (GHC.HsTyVar name) | | Replace each of the name types above with (Located name) | | Updates the haddock submodule. | | Test Plan: ./validate | | Reviewers: austin, goldfire, bgamari | | Reviewed By: bgamari | | Subscribers: goldfire, thomie, mpickering | | Differential Revision: https://phabricator.haskell.org/D1512 | | GHC Trac Issues: #11019 | }}} | | -- | Ticket URL: | <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fghc.h | askell.org<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2faskell.org&…>%2ftrac%2fghc%2fticket%2f11019%23comment%3a5&data=01%7c01%7c | simonpj%40064d.mgd.microsoft.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2f40064d.mgd.…>%7cd486e47f742f47e34e7308d2f39230b0%7c | 72f988bf86f141af91ab2d7cd011db47%7c1&sdata=AmQZ%2boKbdHXQ4cuPjYOVePqF7 | ivXocZyqHXbcyBj3GY%3d> | GHC | <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.h | askell.org<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2faskell.org&…>%2fghc%2f&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2f40064d.mgd.…>%7c | d486e47f742f47e34e7308d2f39230b0%7c72f988bf86f141af91ab2d7cd011db47%7c | 1&sdata=Ca9k88QpvsPGDgrkQCANdKLAPCnAKwoZdHzbIhBgnIU%3d> | The Glasgow Haskell Compiler | _______________________________________________ | ghc-tickets mailing list | ghc-tickets(a)haskell.org<mailto:ghc-tickets@haskell.org> | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h | askell.org<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2faskell.org&…>%2fcgi-bin%2fmailman%2flistinfo%2fghc- | tickets%0a&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2f40064d.mgd.…>%7cd486e47f7 | 42f47e34e7308d2f39230b0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Q | aS%2fcmZrioGbpGHXUFNcdCmhyFt6mnV4DH4ucOsO7eo%3d

1 0