November 2017 - Glasgow-haskell-users

[ANNOUNCE] GHC 8.2.2 released
by Ben Gamari 14 Dec '17

14 Dec '17

=============================================== The Glasgow Haskell Compiler -- version 8.2.2 =============================================== The GHC Team is pleased to announce a new minor release of GHC. This release builds on the performance and stability improvements of 8.2.1, fixing a variety of correctness bugs, improving error messages, and making the compiler more portable. Notable bug-fixes include * A correctness issue resulting in segmentation faults in some FFI-users (#13707, #14346) * A correctness issue resulting in undefined behavior in some programs using STM (#14171) * A bug which may have manifested in segmentation faults in out-of-memory condition (#14329) * clearBit of Natural no longer bottoms (#13203) * A specialisation bug resulting in exponential blowup of compilation time in some specialisation-intensive programs (#14379) * ghc-pkg now works even in environments with misconfigured NFS mounts (#13945) * GHC again supports production of position-independent executables (#13702) * Better error messages around kind mismatches (#11198, #12373, #13530, #13610) A thorough list of the changes in the release can be found in the release notes, https://haskell.org/ghc/docs/8.2.2/html/users_guide/release-8-2-2.html How to get it ~~~~~~~~~~~~~ This release can be downloaded from https://www.haskell.org/ghc/download_ghc_8_2_2.html For older versions see https://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Background ~~~~~~~~~~ Haskell is a standardized lazy functional programming language. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating efficient code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces. GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page https://www.haskell.org/ghc/ GHC developers' home page https://ghc.haskell.org/trac/ghc/ Haskell home page https://www.haskell.org/ Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, is here: https://ghc.haskell.org/trac/ghc/wiki/Contributors Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: https://ghc.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site: https://ghc.haskell.org/trac/ghc/ Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at https://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see https://mail.haskell.org/cgi-bin/mailman/listinfo Many GHC developers hang out on #haskell on IRC: https://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: https://www.haskell.org/ghc/reportabug

2 2

Re: [was ghc-devs] Reasoning backwards with type families
by Anthony Clayden 14 Dec '17

14 Dec '17

> On Thu Nov 16 01:31:55 UTC 2017, David Feuer wrote: (Moving to ghc-users, there's nothing particularly dev-y.) > Sometimes it woulld be useful to be able to reason backwards > about type families. Hi David, this is a well-known issue/bit of a sore. Discussed much in the debate between type families compared to FunDeps. > For example, we have > > type family a && b where > 'False && b = 'False > 'True && b = b > a && 'False = 'False > a && 'True = a > a && a = a > ... if we know something about the *result*, > GHC doesn't give us any way to learn anything about the arguments. You can achieve the improvement you want today. You'll probably find Oleg has a solution With FunDeps and superclass constraints, it'll go like this class (OnResult r a b, OnResult r b a) => And a b r | a b -> r instance And 'False b 'False -- etc, as you'd expect following the tf equations -- the instances are overlapping but confluent class OnResult r a b | r a -> b instance OnResult 'True a 'True instance OnResult 'False 'True 'False You could equally make `OnResult` a type family. If you can trace backwards to where `&&` is used, you might be able to add suitable constraints there. So there's a couple of futures: * typechecker plugins, using an SMT solver * injective type families the next phase is supposed to allow type family a && b = r | r a -> b, r b -> a where ... That will help with some type families (such as addition of Nats), plug1 https://github.com/AntC2/ghc-proposals/blob/instance-apartness-guards/propo… but I don't see it helping here. plug2 (this example) https://github.com/AntC2/ghc-proposals/blob/instance-apartness-guards/propo… Because (for example) if you unify the first two equations, (that is, looking for coincident overlap) 'False && 'False = 'False 'True && 'False = 'False That's inconsistent on dependency ` r b -> a`. And you can't fix it by re-ordering the closed equations. > For (&&), the obvious things you'd want are ... > > There's nothing inherently impossible about this sort of reasoning. No-ish but. It relies on knowing kind `Bool` is closed. And GHC doesn't pay attention to that. So you need to bring type family `Not` into the reasoning; hence a SMT solver. > ... > I wouldn't necessarily expect GHC > to be able to work something like this out on its own. That's a relief ;-) > But it seems like there should be some way to allow the user > to guide it to a proof. Yes, an SMT solver with a model for kind `Bool`. (And a lot of hard work to teach it, by someone.) AntC

4 9

uninstalling libraries
by Evan Laforge 13 Nov '17

13 Nov '17

For a very long time, I've used a local script to uninstall libraries. Initially it was very simple: use ghc-pkg field to find and remove library-dirs, import-dirs, and haddock-html, and call ghc-pkg unregister. It served well for a long time, but eventually I got tired of copy paste games and extended it to be able to recursively delete dependents too. Unfortunately now it's no longer so simple. The main problem is that the only way I know to find dependents is to ghc-pkg unregister, and see what the error message complains about. That's obviously pretty bad, since by that time you've already unregistered, so it's too late to back out. The non-atomic nature of unregister+rm has always caused problems anyway, since if unregister succeeds, but the remove fails, we are stuck with a partial install. Recursive delete is too error prone, so I reverted that. And then I discovered that hmatrix helpfully includes /opt/local/lib and /usr/local/lib in its library-dirs, so clearly just deleting whatever the package tells me is not very safe. All this has led me to believe uninstalling packages is not so simple, and maybe there should be an actual real way to do it, not everyone hacking up their own dangerous shell scripts. So... is there? Should there be one? Is there interest in one? How do other people uninstall libraries? Is there a better interface to the pkg db than ghc-pkg? Is there a better way to find dependents than ghc-pkg unregister?

4 8

Why is scanr strict in its third argument?
by Geraint Jones 09 Nov '17

09 Nov '17

There are two things you might think of when you think of scanr; or rather, there are two things I think of: a specification scanr f e = map (foldr f e) . tails and an implementation scanr f e = foldr g [e] where g x yss@(ys:_) = f x ys : yss Of course these two differ, because the one I called an implemntation is strict wheras the specification isn't. I wouldn't mind, but scanl goes to the trouble of not being strict, as does Data.List.tails, which means inter alia that scanr (:) [] is not an implementation of Data.List.tails as you might have expected. (Well, as I did.) In the context of > arb = error "not used in demo" > bot = error "bottom" you get *Main> (null . map (foldr arb arb) . Data.List.tails) bot False *Main> (null . scanr arb arb) bot *** Exception: bottom *Main> (null . scanl arb arb) bot False

2 1

Re: Proposal: Instance apartness guards
by Anthony Clayden 08 Nov '17

08 Nov '17

Surprisinlgy little comment on this proposal. Perhaps it landed when yous were busy elsewhere. I'd like to push it to the committee soon; this is an invitation for more feedback. Richard E wrote a nice brief summary https://github.com/ghc-proposals/ghc-proposals/pull/56#issuecomment-3114214… Thank you AntC ----- Original Message Follows ----- > After years of pondering this idea (in various forms), > and several rounds of discussion on several forums, > I've written it up. > > "This proposal tackles the thorny topic of Overlapping > instances, > for both type classes and Type Families/Associated types, > by annotating instance heads with type-level apartness > Guards. > Type-level disequality predicates appear in Sulzmann & > Stuckey 2002; > in the type-level case selection in HList 2004; > and in various guises in Haskell cafe discussions in > following years. > This proposal builds on the apartness testing implemented > as part of the Closed Type Families work." > > All feedback welcome. > > https://github.com/AntC2/ghc-proposals/blob/instance-apartness-guards/propo… > > AntC

1 0

Re: [Haskell-cafe] [ANNOUNCE] GHC 8.2.2 release candidate 2
by Sven Panne 06 Nov '17

06 Nov '17

2017-11-05 15:37 GMT+01:00 <jpaugh(a)gmx.com>: > A better approach might be to develop a "machine-readable" output format > which then is kept stable, and can be enabled with a flag. Git has a > similar solution. > Without doubt, this is definitely the better approach, but this is hardly what can be achieved for 8.2.2. Adding some flag to get the old behavior back when wanted *is* achievable. > It would be a shame to avoid changes which make the user experience better > simply because other projects cannot sync their development cycle, > Don't get me wrong: I'm all for improving user experience, but making ad hoc changes without enough thought or even a chance to get the old behavior back is probably not the right way to proceed. All SW lives in some kind of ecosystem, so it should behave well in that. And for Emacs users, the user experience has been made much worse. > especially if those projects are not universally used or required. > This is highly a matter of personal taste: No project is "universally used", so this is tautological statement. The question is: Is a minor cosmetic change really worth breaking things in one of the major IDEs? Cheers, S.

2 2

[ANNOUNCE] GHC 8.2.2 release candidate 2
by Ben Gamari 05 Nov '17

05 Nov '17

Hello everyone, The GHC team is very pleased to announce the second candidate of the 8.2.2 release of the Glasgow Haskell Compiler. Source and binary distributions are available at https://downloads.haskell.org/~ghc/8.2.2-rc2/ This is the second and hopefully last of two release candidates leading up the final 8.2.2 release. This release fixes approximately fifty bugs present in 8.2.1. These most notably include, * A correctness issue resulting in segmentation faults in some FFI-users (#13707, #14346) * A correctness issue resulting in undefined behavior in some programs using STM (#14171) * A bug which may have manifested in segmentation faults in out-of-memory condition (#14329) * clearBit of Natural no longer bottoms (#13203) * A specialisation bug resulting in exponential blowup of compilation time in some specialisation-intensive programs (#14379) * ghc-pkg now works even in environments with misconfigured NFS mounts (#13945) * GHC again supports production of position-independent executables (#13702) * Better error messages around kind mismatches (#11198, #12373, #13530, #13610) See [1] for the full list. As always, please report any issues you encounter. Happy testing, - Ben [1] https://ghc.haskell.org/trac/ghc/query?status=closed&milestone=8.2.2&col=id…

3 2

Annotations with names
by Joachim Breitner 04 Nov '17

04 Nov '17

Hi, I’d like to use Annotations to transport some meta-information from the Haskell source to GHC Plugins (as they are meant to be, right?). But I am struggling expressing annotations that relate different symbols. Here are some hypthetical examples what I want to express: foo :: String -> String foo = … bar :: [(String,String), (String, String)] {-# ANN bar (TestCasesFor 'foo) #-} rec :: Natural -> (a -> a) -> a -> a {-# ANN rec (RecurserFor 'Natural) $-} This code actually works (with TemplateHaskell). It will put a TH.Name into the annotations, but when I am in Core, I need a core Name. Is there a good way of transporting such references in Annotations so that the desugarer (or the renamer) will do the necessary name changes for me? And slightly related: Do Annotations keep bindings alive? (It seems so, but then it should be documented in https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/extending_g… Thanks, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de https://www.joachim-breitner.de/

1 0