- Glasgow-haskell-users

uninstalling libraries
by Evan Laforge 14 Nov '17

14 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

[ANNOUNCE] GHC 8.2.2 release candidate 3
by Ben Gamari 31 Oct '17

31 Oct '17

Hello everyone, The GHC team is very pleased to announce the third 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-rc3/ This is the third and last of three 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. Release candidate three contains only two patches not present in -rc2 but fixes a packaging issue which lead to unintentional downgrading the process and Cabal libraries. 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…

1 0

How does GHC's testsuite work?
by Sébastien Hinderer 31 Oct '17

31 Oct '17

Dear all, I am a member of OCaml's developement team. More specifically, I am working on a test-driver for the OCaml compiler, which will be part of OCaml's 4.06 release. I am currently writing an article to describe the tool and its principles. In this article, I would like to also talk about how other compilers' testsuites are handled and loking how things are done in GHC is natural. In OCaml, our testsuite essentially consist in whole programs that we compile and run, checking that the compilation and execution results match the expected ones. >From what I could see from GHC's testsuite, it seemed to me that it uses Python to drive the tests. I also understood that the testsuite has tests that are more kind of unit-tests, in the .T file. Am I correct here? Or do you guys also have whole program tests? If you do, how do you compile and run them? Any comment / hint on this aspect of the test harness' design would be really helpful. Many thanks in advance, Sébastien.

4 7

Getting segmentation fault on stack/cabal -any command, including stack --install-ghc, On windows.
by Michael McCulloch 22 Oct '17

22 Oct '17

Hello. After searching around I can't find people with a similar issue (Maybe I'm looking in the wrong places?). I installed Haskell platform 8.2.1, using Stack 1.5.1, Cabal 2.0.0.0. Windows 10 Fall Creators Update( This issue was also occurring pre FCU). The issue also occurs with 8.0.2a Prior to FCU, I could run ghci directly, but now i get: Access violation in generated code when reading 00000000046710f6 Can anyone help me out? -- Michael McCulloch c: (403) 629-9645 e: michael.james.mcculloch(a)gmail.com

2 8

GHC rewrite rule type-checking failure
by Conal Elliott 04 Oct '17

04 Oct '17

I'm running into type checking problem with GHC rewrite rules in GHC 8.0.2, illustrated in the code below. The first rule type-checks, but the second triggers the type error mentioned in the comment following the rule definition. I'd expect both rules to type-check, adding the needed constraints to the applicability condition for the rule. Is GHC's behavior intended (and perhaps necessary), or a bug? Thanks, -- Conal Code (also attached): {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# OPTIONS_GHC -Wall #-} -- Demonstrate a type checking failure with rewrite rules module RuleFail where class C k where comp' :: k b c -> k a b -> k a c instance C (->) where comp' = (.) -- Late-inlining version to enable rewriting. comp :: C k => k b c -> k a b -> k a c comp = comp' {-# INLINE [0] comp #-} morph :: (a -> b) -> k a b morph = error "morph: undefined" {-# RULES "morph/(.)" morph comp = comp #-} -- Fine class D k a where addC' :: k (a,a) a instance Num a => D (->) a where addC' = uncurry (+) -- Late-inlining version to enable rewriting. addC :: D k a => k (a,a) a addC = addC' {-# INLINE [0] addC #-} {-# RULES "morph/addC" morph addC = addC #-} -- Fail -- • Could not deduce (D k b) arising from a use of ‘addC’ -- from the context: D (->) b -- Why does GHC infer the (C k) constraint for the first rule but not (D k b) -- for the second rule?

4 9