- Glasgow-haskell-users

Reconsidering -Wall and -Wcompat
by Ben Gamari 15 Feb '16

15 Feb '16

tl;dr. GHC has a new set of warnings, -Wcompat, intended to give users advance notice of coming library changes. We want to know whether you think this set should be included in -Wall. See the Wiki [4] and voice your opinion via the linked poll. Hello everyone, GHC 8.0.1 will include a new warning group, -Wcompat, which arose out of the MonadFail proposal discussion [1] late last year. This warning set is intended to provide a means of informing users of coming changes in GHC's core libraries. We would like to solicit the community's feedback on whether this new flag set should be implied by -Wall. This proposal is motivated by concern expressed by some that -Wcompat would see little usage unless it is placed in one of the warning sets typically used during development. One such set is -Wall, which enables a generous fraction of GHC's warning collectionand is is intended [2] for use during development. Unfortunately, despite the (albeit only recently stated) intent of flag, -Wall is widely used outside of development [3], often with the expectation that the result be warning-clean across multiple GHC versions. While we hope that -Wall will see less use in this context in the future, given its current role we wouldn't want to add options to it that would cause undue burden for users. So, we are asking for your opinion: should -Wcompat be implied by -Wall? You can find a more thorough description of the precise proposal on the GHC Wiki [4]. It would be very much appreciated if you could take a few minutes familiarize yourself with the options and provide your thoughts via this quick poll, https://docs.google.com/forms/d/1BmIQvhHcnDB79LgBvaWl_xXpS1q0dMHe3Gq9JeU9od… Feel free to discuss the issue further in this thread. Thank you for sharing, - Ben [1] https://mail.haskell.org/pipermail/ghc-devs/2015-October/010101.html [2] https://mail.haskell.org/pipermail/ghc-devs/2016-January/010955.html [3] In a rather unscientific study, nearly half of packages on Hackage include it in ghc-options, $ tar -xf ~/.cabal/packages/00-INDEX.tar $ (for pkg in $(ls); do ls $pkg/*/*.cabal | sort -r | head -n1; done) | xargs grep -L '\-Wall' | wc -l 4352 $ ls | wc -l 9347 [4] https://ghc.haskell.org/trac/ghc/wiki/Design/Warnings/Wcompat

8 11

LANGUAGE ConstraintKinds not needed to use ConstraintKinds?
by Evan Laforge 15 Feb '16

15 Feb '16

I recently upgraded to ghc 8 and started using stacks via ImplicitParams. For that I wind up using 'type Stack = (?stack :: CallStack)' and so ContraintKinds (I see that in the future GHC will do this by default). So now I can have a file like: module T where import qualified Log as Log f :: Log.Stack => IO () f = Log.warn "blah blah" I noticed that now haskell-src-exts refuses to parse this file, saying 'MultiParamTypeClasses language extension is not enabled.'. I assume it's a bug with haskell-src-exts in that it should require LANGUAGE ConstraintKinds instead, but then GHC itself doesn't want ConstraintKinds. Instead, it wants FlexibleContexts. From the docs, FlexibleContexts seems to be about the contexts in instance heads. Is this intentional? I'll go ahead and make a bug for haskell-src-exts, but the ghc behaviour here seems odd as well. What extension should haskell-src-exts require to parse this?

2 4

[ANNOUNCE] GHC 8.0.1 release candidate 2
by Ben Gamari 08 Feb '16

08 Feb '16

Hello everyone, The GHC Team is very pleased to announce the second release candidate of the Glasgow Haskell Compiler 8.0.1 release. Source and binary distributions as well as the newly revised users guide and Haddock documentation can be found at http://downloads.haskell.org/~ghc/8.0.1-rc2/ This is the second in a series of release candidates leading up to the 8.0.1 release and fixes many of the issues reported in -rc1. These fixes include, * A re-rewrite of the pattern checker by George Karachalias. The new checker should have far more predictable performance characteristics while sacrificing minimal reasoning power. This should resolve a large number of the issues felt in -rc1. * Richard Eisenberg has been hammering out all manner of type-application- and TypeInType-related issues (#11335, #11416, #11405). There is still more work to do here, however (e.g. #11471). * Matthew Pickering has restored support for multi-clause pattern synonyms (#11367) * A latent bug in the constraint solver which popped up as a build failure in xmonad-contrib in -rc1 has been fixed (#11379) * Dimitrios Vytiniotis and Simon Peyton Jones has been squashing a variety of older type-checker bugs at a furious rate (#11458, #11248, #11330, #11408) * Simon Peyton Jones has taught demand analysis to more precisely handle exceptions (#11222) * Tamar Christina has added support for remote GHCi on Windows and resolved a long-standing linking issue (#11223) * Loading of compiled modules needing shared library symbols now works in GHCi thanks to Peter Trommler (#10458) * A variety of limitations in our implementation of Typeable implementation have been fixed (#11120) although there is still more to be done (#11334). * A terrible failure of type inference due to visible type application has been fixed (#11458) * InjectiveTypeFamilies has been renamed to TypeFamilyDependencies * Custom type errors are now more robust (#11391) although there is still more work to be done (#11541) * We now have a more conservative default warning set, as well as better mechanisms for managing warning changes in the future. (#11429, #11370) * Compatibility with earlier Cabal versions should be a bit more robust. * The user-facing interface of the (formerly "implicit") CallStack functionality has been reworked, hiding the implicit callstack parameter behind a constraint synonym. * Online haddock documentation has been restored (#11419) * We now offer xz archives exclusively * A variety of miscellaneous bug-fixes have also been merged. All of these changes add up to nearly 200 commits in total. Given the large amount of churn between this candidate and -rc1, as well as the fact that there is at least one more significant patch pending (D1891, to fix #11471 and others), we will be releasing a third release candidate in a few weeks which should address more of the issues listed on the release status page [1]. Assuming things go well, we should be able to cut a final release by early March at the latest. All of the builds above were produced from the ghc-8.0.1-rc2 tag (commit e2230228906a1c0fa1f86a0c1aa18d87de3cc49d) *with the exception of the Windows builds*. Unfortunately, it was realized only too late that the tagged commit is broken on Windows. Consequently, the Windows builds were produced from the ghc-8.0.1-rc2 tag with two additional patches (commit 5b35c5509adb1311856faa0bc9767aec9ad5e9b7). While this would of course be completely unacceptable for a proper release, time constraints have meant that this was unfortunately the only viable option for this release candidate. We apologize for any confusion this may cause. At this point we are working very hard to nail the remaining bugs labelled as "highest" priority on the 8.0.1 status page [1]. If you have an issue which you'd like to see addressed in the release that does not appear in this list, please bring it to our attention. As always, we look forward to hearing about any issues that you encounter with this candidate. Thanks to everyone who has contributed so far! Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1

3 6

problem compiling GHC 8.0.1 release candidate 2 src on Apple
by George Colpitts 07 Feb '16

07 Feb '16

"/usr/local/bin/ghc" -M -static -H32m -O -Wall -package-db libraries/bootstrapping.conf -this-unit-id terminfo-0.4.0.2 -hide-all-packages -i -ilibraries/terminfo/. -ilibraries/terminfo/dist-boot/build -ilibraries/terminfo/dist-boot/build/autogen -Ilibraries/terminfo/dist-boot/build -Ilibraries/terminfo/dist-boot/build/autogen -Ilibraries/terminfo/. -optP-include -optPlibraries/terminfo/dist-boot/build/autogen/cabal_macros.h -package-id base-4.9.0.0 -Wall -XHaskell2010 -no-user-package-db -rtsopts -fno-warn-unused-imports -fno-warn-deprecated-flags -odir libraries/terminfo/dist-boot/build -hidir libraries/terminfo/dist-boot/build -stubdir libraries/terminfo/dist-boot/build -dep-makefile libraries/terminfo/dist-boot/build/.depend-v.haskell.tmp -dep-suffix "" -include-pkg-deps libraries/terminfo/./System/Console/Terminfo.hs libraries/terminfo/./System/Console/Terminfo/Base.hs libraries/terminfo/./System/Console/Terminfo/Cursor.hs libraries/terminfo/./System/Console/Terminfo/Color.hs libraries/terminfo/./System/Console/Terminfo/Edit.hs libraries/terminfo/./System/Console/Terminfo/Effects.hs libraries/terminfo/./System/Console/Terminfo/Keys.hs ghc: unrecognised flag: -this-unit-id Usage: For basic information, try the `--help' option. make[1]: *** [libraries/terminfo/dist-boot/build/.depend-v.haskell] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [all] Error 2 ghc --info [("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts"," -fwrapv -fno-builtin") ,("C compiler command","/usr/local/bin/gcc") ,("C compiler flags"," -m64 -fno-stack-protector") ,("C compiler link flags"," -m64") ,("Haskell CPP command","/usr/local/bin/gcc") ,("Haskell CPP flags","-E -undef -traditional") ,("ld command","/usr/bin/ld") ,("ld flags"," -arch x86_64") ,("ld supports compact unwind","YES") ,("ld supports build-id","NO") ,("ld supports filelist","YES") ,("ld is GNU ld","NO") ,("ar command","/usr/bin/ar") ,("ar flags","clqs") ,("ar supports at file","NO") ,("touch command","touch") ,("dllwrap command","/bin/false") ,("windres command","/bin/false") ,("libtool command","libtool") ,("perl command","/usr/bin/perl") ,("cross compiling","NO") ,("target os","OSDarwin") ,("target arch","ArchX86_64") ,("target word size","8") ,("target has GNU nonexec stack","False") ,("target has .ident directive","True") ,("target has subsections via symbols","True") ,("Unregisterised","NO") ,("LLVM llc command","llc") ,("LLVM opt command","opt") ,("Project version","8.0.0.20160111") ,("Project Git commit id","497454fc6610d67a2b2cd7902390c6497bddb483") ,("Booter version","7.10.2") ,("Stage","2") ,("Build platform","x86_64-apple-darwin") ,("Host platform","x86_64-apple-darwin") ,("Target platform","x86_64-apple-darwin") ,("Have interpreter","YES") ,("Object splitting supported","YES") ,("Have native code generator","YES") ,("Support SMP","YES") ,("Tables next to code","YES") ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn l_dyn thr_l_dyn") ,("RTS expects libdw","NO") ,("Support dynamic-too","YES") ,("Support parallel --make","YES") ,("Support reexported-modules","YES") ,("Support thinning and renaming package flags","YES") ,("Requires unified installed package IDs","YES") ,("Uses package keys","YES") ,("Dynamic by default","NO") ,("GHC Dynamic","YES") ,("GHC Profiled","NO") ,("Leading underscore","YES") ,("Debug on","False") ,("LibDir","/usr/local/lib/ghc-8.0.0.20160111") ,("Global Package DB","/usr/local/lib/ghc-8.0.0.20160111/package.conf.d") ] On Sun, Feb 7, 2016 at 2:13 PM, Ben Gamari <ben(a)well-typed.com> wrote: > > Hello everyone, > > The GHC Team is very pleased to announce the second release candidate of > the Glasgow Haskell Compiler 8.0.1 release. Source and binary > distributions as well as the newly revised users guide and Haddock > documentation can be found at > > http://downloads.haskell.org/~ghc/8.0.1-rc2/ > > This is the second in a series of release candidates leading up to the > 8.0.1 > release and fixes many of the issues reported in -rc1. These fixes > include, > > * A re-rewrite of the pattern checker by George Karachalias. The new > checker should have far more predictable performance characteristics > while sacrificing minimal reasoning power. This should resolve a > large number of the issues felt in -rc1. > > * Richard Eisenberg has been hammering out all manner of > type-application- and TypeInType-related issues (#11335, #11416, > #11405). There is still more work to do here, however (e.g. #11471). > > * Matthew Pickering has restored support for multi-clause pattern > synonyms (#11367) > > * A latent bug in the constraint solver which popped up as a build > failure in xmonad-contrib in -rc1 has been fixed (#11379) > > * Dimitrios Vytiniotis and Simon Peyton Jones has been squashing a > variety of older type-checker bugs at a furious rate (#11458, > #11248, #11330, #11408) > > * Simon Peyton Jones has taught demand analysis to more precisely > handle exceptions (#11222) > > * Tamar Christina has added support for remote GHCi on Windows > and resolved a long-standing linking issue (#11223) > > * Loading of compiled modules needing shared library symbols now works > in GHCi thanks to Peter Trommler (#10458) > > * A variety of limitations in our implementation of Typeable > implementation have been fixed (#11120) although there is still more > to be done (#11334). > > * A terrible failure of type inference due to visible type application > has > been fixed (#11458) > > * InjectiveTypeFamilies has been renamed to TypeFamilyDependencies > > * Custom type errors are now more robust (#11391) although there is > still more work to be done (#11541) > > * We now have a more conservative default warning set, as well as > better mechanisms for managing warning changes in the future. > (#11429, #11370) > > * Compatibility with earlier Cabal versions should be a bit more > robust. > > * The user-facing interface of the (formerly "implicit") CallStack > functionality has been reworked, hiding the implicit callstack > parameter behind a constraint synonym. > > * Online haddock documentation has been restored (#11419) > > * We now offer xz archives exclusively > > * A variety of miscellaneous bug-fixes have also been merged. > > All of these changes add up to nearly 200 commits in total. Given the > large amount of churn between this candidate and -rc1, as well as the > fact that there is at least one more significant patch pending (D1891, > to fix #11471 and others), we will be releasing a third release > candidate in a few weeks which should address more of the issues listed > on the release status page [1]. Assuming things go well, we should be > able to cut a final release by early March at the latest. > > All of the builds above were produced from the ghc-8.0.1-rc2 tag (commit > e2230228906a1c0fa1f86a0c1aa18d87de3cc49d) *with the exception of the > Windows builds*. Unfortunately, it was realized only too late that the > tagged commit is broken on Windows. Consequently, the Windows builds > were produced from the ghc-8.0.1-rc2 tag with two additional patches > (commit 5b35c5509adb1311856faa0bc9767aec9ad5e9b7). While this would of > course be completely unacceptable for a proper release, time constraints > have meant that this was unfortunately the only viable option for this > release candidate. We apologize for any confusion this may cause. > > At this point we are working very hard to nail the remaining bugs > labelled as "highest" priority on the 8.0.1 status page [1]. If you have > an issue which you'd like to see addressed in the release that does not > appear in this list, please bring it to our attention. > > As always, we look forward to hearing about any issues that you > encounter with this candidate. Thanks to everyone who has contributed so > far! > > Cheers, > > - Ben > > > [1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1 > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > >

2 1

Dropping bzip2 release tarballs?
by Ben Gamari 02 Feb '16

02 Feb '16

tl;dr do you rely on the .bz2 release tarballs on downloads.haskell.org? If so, let us know! Hello everyone, As you may have noticed, a few releases ago we started producing xz-compressed binary distributions in addition to the usual bzip2 tarballs. While preparing 8.0.1-rc1 it was suggested that we move to distributing xz tarballs exclusively. Not only would this move reduce storage and bandwidth demands on our infrastructure but it would also simplify the job of producing the distributions. Indeed there is plenty of precendent for projects who have moved exclusively to xz (the Linux kernel and git being two examples). Of course, these reasons alone aren't sufficient to abandon those who might rely on our bzip2 tarballs. If you feel strongly that we should continue to distribute bzip2 tarballs, please let us know. Thanks! - Your friendly GHC packaging gnomes

3 3

GHC 8.0.1 plans
by Ben Gamari 27 Jan '16

27 Jan '16

tl;dr: The march towards 8.0.1 continues. Release candidate 2 will likely be cut late next week. If you have a ticket which you'd like to see addressed but suspect we aren't working on then please say so. Hello again GHC-ers, As you likely know, we are currently in the stabilization period of GHC's 8.0.1 release. Release candidate 1 has been out for nearly two weeks now and issues have been steadily trickling in. The problems we've heard about thusfar have largely fallen into a few broad categories, * OS X linker issues due to botched preparation of the first binary distribution (#11423) * pattern match checker performance. These we largely knew about prior to the release, although it has been surprising to see how easily one can wander into the new checker's performance abyss. (#11374, #11276, #11163, #11302, #11303, #11195) * Regressions due to visible type applications (#11329, #11458) * Issues uncovered by generalizations allowed under TypeInType (#11429, #11334, #11473, #11405, #11407, #11399) * Trouble caused by new warnings (#11370, #11316, #11474) Since the release, there has been significant progress on many of these fronts: * George Karachalias has been hard at work further improving the pattern checker. The result should have far more predictable performance characteristics at less cost in reasoning power. * Simon Peyton Jones has been squashing bugs at a furious rate, including a variety of long-standing issues (#11248, #11330 and many others) * Tamar Christina has added support for remote GHCi on Windows and resolved a long-standing linking issue (#11223, #11100) * A variety of limitations in our implementation of Typeable have been fixed (#11120) although there is still more to be done (#11334). * InjectiveTypeFamilies has been renamed to TypeFamiliesDependencies * Custom type errors are now more robust (#11391) * We now have a more conservative default warning set, as well as better mechanisms for managing warning changes in the future. (#11429, #11370) * A wide variety of miscellaneous bug-fixes have also been merged. Given how much progress has been made, we approaching the point where we can begin planning the next candidate. At this point the plan is to wait until we have landed George's pattern checker rework, as this has been one of the more visible issues in practice. This may be merged as early as the latter half of next week. If this happens then we hope to have the next release candidate out late next week. In the interim we will continue to work on paring down the bug list, focusing on the highest priority tickets listed on the 8.0.1 status page. In particular, those with owners are most likely to be dealt with soon. If you see a ticket which you would like to see addressed in 8.0.1 but is unowned or lower than "highest" priority, please bring this to our attention. Given the large amount of churn still being felt in the `ghc-8.0` branch (with over 150 comments in the two weeks since -rc1) and the size of some of the patches that have yet to land, it's unclear whether two release candidates will be sufficient to ensure the stability of the branch. Consequently, unless -rc2 yields a particularly small number of new tickets it's likely that it will be followed by a third candidate before the release. As always, let us know if you have any questions or concerns about the release process. Thanks to everyone who has contributed to -rc1! Cheers, - Ben

1 0

Were usage types ever in GHC
by Philip Dexter 22 Jan '16

22 Jan '16

I've recently been digging around to see if there has ever been any attempt to perform any sort of data reuse optimization in functional languages. Along with many other papers, I've come across `Once upon a type' as well as `Once upon a polymorphic type'. They both mention a desire to include a similar system in GHC. Then in `Playing by the rules: rewriting as a practical optimization technique in GHC' I see usage types mentioned in section 5.3: """ To express this, GHC adds extra usage type arguments to map, both at its definition and at its call sites. Once this is done, a specialised version of map can be compiled for the case when the usage-type argument is “once”, and a rule generated to match such calls, in exactly the same way as for specialising overloading. """ I can't tell if this is simply a hypothetical optimization or if this really happened at one point in the history of GHC. I was hoping somebody could shed some light on this topic Was a usage type system or something similar (e.g. linear type system) ever present in GHC? If it was then why was it taken out (unless I'm missing something, this optimization is not happening today)? I could guess at this and say that the gains weren't worth the overhead, but perhaps there's another reason. If it was never present, why not? There was obviously at least some interest in this sort of optimization at some point in the Haskell community and I'd be curious as to why it was never tested in GHC. Thanks! Philip Dexter

2 1

suppress warning "Defined but not used: type variable ‘x’" in GHC-8.0
by Henning Thielemann 18 Jan '16

18 Jan '16

GHC-8.0 emits several new warnings of this kind: Defined but not used: type variable ‘x’ for declarations like type instance Snd x y = y Enthusiastically, I started to replace unused type function arguments by underscores, only to find out that older GHC versions do not accept that. With what option can I disable this warning? Or can it be removed from -Wall for now?

7 10

Warnings, -Wall, and versioning policy
by Simon Marlow 13 Jan '16

13 Jan '16

Hi folks, We haven't described what guarantees GHC provides with respect to -Wall behaviour across versions, and as a result there are some differing expectations around this. It came up in this weeks' GHC meeting, so we thought it would be a good idea to state the policy explicitly. Here it is: We guarantee that code that compiles with no warnings with -Wall ("Wall-clean") and a particular GHC version, on a particular platform, will be Wall-clean with future minor releases of the same major GHC version on the same platform. (we plan to put this text in the User's Guide for future releases) There are no other guarantees. In particular: - In a new major release, GHC may introduce new warnings into -Wall, and/or change the meaning of existing warnings such that they trigger (or not) under different conditions. - GHC may generate different warnings on different platforms. (examples of this are -fwarn-overflowed-literals and -fwarn-unsupported-calling-conventions) Some rationale: - We consider any change to the language that GHC accepts to be a potentially code-breaking change, and subject to careful scrutiny. To extend this to warnings would be a *lot* of work, and would make it really difficult to introduce new warnings and improve the existing ones. - Warnings can be based on analyses that can change in accuracy over time. The -fwarn-unused-imports warning has changed a lot in what it rejects, for example. - We often introduce new warnings that naturally belong in -Wall. If -Wall was required to be a fixed point, we would have to start introducing new flags, and versioning, etc. and even keep the old implementation of warnings when they change. It would get really messy. There are some consequences to this. -Wall -Werror is useful for keeping your code warning-clean when developing, but shipping code with these options turned on in the build system is asking for trouble when building your code with different GHC versions and platforms. Keep those options for development only. Hackage already rejects packages that include -Wall for this reason. One reason we're raising this now is that it causes problems for the 3-release policy (https://prime.haskell.org/wiki/Libraries/3-Release-Policy) which requires that it be possible to write code that is Wall-clean with 3 major releases of GHC. GHC itself doesn't guarantee this, so it might be hard for the core libraries committee to provide this guarantee. I suggest this requirement be dropped from the policy. Cheers, Simon

3 4

Re: Optimization of IORefs and STRefs - comparison to g++
by Henning Thielemann 09 Jan '16

09 Jan '16

How about just using alloca, peek and poke - like C guys do in order to get C's speed?

1 0