- ghc-devs - Haskell.org

ok to do reformatting commits?
by Evan Laforge 03 Dec '15

03 Dec '15

When I was doing a recent patch, I was annoyed by lint errors about >80 lines when I was just conforming to the existing style. To avoid cluttering my commit with unrelated changes, I decided to fix the lints in a formatting-only commit afterwards. Looking in the archives, I see there was some recent discussion about this, but I didn't see anyone volunteering to just go wrap a bunch of files, or saying that they didn't want anyone to do this (usual reason being cluttering the history, which as a rationale to not do formatting only changes never sat too well with me). Would anyone mind if I went and wrapped a bunch of files, say typecheck/*.hs? This seems simpler than either constant hassling from arc or coming up with more elaborate rules for arc. I would have to make some formatting decisions, so likely to some eyes I would be messing some stuff up, but since there's no real standard that is probably unavoidable.

5 6

HEADS UP: Moving Phabricator to a new server soon
by Austin Seipp 02 Dec '15

02 Dec '15

Hello all, As I said about a week or two ago[1], I still have plans to move the Phabricator server. I'd like to do this tonight. I plan on starting this around 10pm CST or so. This is late at night in the US and quite early in the EU, so I'm hoping to avoid causing problems for anyone. I'll follow up with more emails in response to this one later tonight, as things move forward. Thanks! [1] https://mail.haskell.org/pipermail/ghc-devs/2015-November/010519.html -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

linker error in haddock, D1558
by Alan & Kim Zimmerman 01 Dec '15

01 Dec '15

Does anyone know why a build would be failing with utils/haddock/dist/build/Haddock/GhcUtils.dyn_o: In function `skOK_info': (.text+0x75c8): undefined reference to `stg_ap_0_upd_info' utils/haddock/dist/build/Haddock/GhcUtils.dyn_o: In function `skP5_info': (.text+0x7728): undefined reference to `stg_ap_0_upd_info' collect2: error: ld returned 1 exit status `gcc' failed in phase `Linker'. (Exit code: 1) utils/haddock/ghc.mk:21: recipe for target 'utils/haddock/dist/build/tmp/haddock' failed make[1]: *** [utils/haddock/dist/build/tmp/haddock] Error 1 This is happening on https://phabricator.haskell.org/harbormaster/build/8393/, a build of https://phabricator.haskell.org/D1558 Alan

1 0

Wildcard refactoring
by Simon Peyton Jones 01 Dec '15

01 Dec '15

OK, I think it’s time to commit my branch wip/spj-wildcard-refactor Ben: could you commit it as a single large patch (ignore the branch history). A commit message appears below. There is a corresponding patch for haddock, with same branch name in the haddock repo. Could you also open a ticket for the performance regression on perf/compiler/T3064? I don’t want to forget it, but it’s past time to commit such a big, invasive patch. There are two other tests failing for me, which appear to do with the version number for the containers sub-module. I think I have failed to get the other submodules (other than haddock) right. I was NOT intending to change them, so just use origin/master for them. Everyone: take a look at the commit message below. I’ve been working on this for far too long, in spare moments. Richard, I’m sorry that it’ll be disruptive to your changes, but in a good way I hope. Simon This patch began as a modest refactoring of HsType and friends, to clarify and tidy up exactly where quantification takes place in types. Although initially driven by making the implementation of wildcards more tidy (and fixing a number of bugs), I gradually got drawn into a pretty big process, which I've been doing on and off for quite a long time. There is one compiler performance regression as a result of all this, in perf/compiler/T3064. I still need to look into that. * The principal driving change is described in Note [HsType binders] in HsType. Well worth reading! * Those data type changes drive almost everything else. In particular we now statically know where (a) implicit quantification only (LHsSigType), e.g. in instance declaratios and SPECIALISE signatures (b) implicit quantification and wildcards (LHsSigWcType) can appear, e.g. in function type signatures * As part of this change, HsForAllTy is (a) simplified (no wildcards) and (b) split into HsForAllTy and HsQualTy. The two contructors appear when and only when the correponding user-level construct appears. Again see Note [HsType binders]. HsExplicitFlag disappears altogether. * Other simplifications - ExprWithTySig no longer needs an ExprWithTySigOut variant - TypeSig no longer needs a PostRn name [name] field for wildcards - PatSynSig records a LHsSigType rather than the decomposed pieces - The mysterious 'GenericSig' is now 'ClassOpSig' * Renamed LHsTyVarBndrs to LHsQTyVars * There are some uninteresting knock-on changes in Haddock, because of the HsSyn changes I also did a bunch of loosely-related changes: * We already had type synonyms CoercionN/CoercionR for nominal and representational coercions. I've added similar treatment for TcCoercionN/TcCoercionR mkWpCastN/mkWpCastN All just type synonyms but jolly useful. * I record-ised ForeignImport and ForeignExport * I improved the (poor) fix to Trac #10896, by making TcTyClsDecls.checkValidTyCl recover from errors, but adding a harmless, abstract TyCon to the envt if so. * I did some significant refactoring in RnEnv.lookupSubBndrOcc, for reasons that I have (embarrassingly) now totally forgotten. It had to do with something to do with import and export

2 1

Wildcards in type functions vs. named wild cards
by Jan Stolarek 01 Dec '15

01 Dec '15

Simon, One of my students (Michał, CCd) is hacking on #10982 and he noticed a rather unexpected behaviour. If I say: {-# LANGUAGE TypeFamilies #-} module T10982 where type family F a where F _t = Int Then everything is fine. But if I enable NamedWildCards extension then suddenly this code is rejected: T10982.hs:7:7: error: Unexpected wild card: ‘_t’ In the declaration for type synonym ‘F’ I am 99% sure this is a bug and the program should be accepted even with NamedWildCards. Am I correct? Does this interact in any way with your upcomming refactoring of wildcards? Janek --- Politechnika Łódzka Lodz University of Technology Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata. Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system.

2 2

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