January 2016 - Glasgow-haskell-users

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