- Glasgow-haskell-users

overlapping instances in 7.10.1
by Sergei Meshveliani 16 Jun '15

16 Jun '15

Dear GHC developers, This request overrides my previous one of "7.10.1-err..." (it is simpler and more precise). The archive http://www.botik.ru/pub/local/Mechveliani/ghcQuest/7.10.1-errReport-may23-2… presents a question about ghc-7.10.1. Make it, please, with ghc-7.10.1 by ghc $doconCpOpt -O --make Main , $doconCpOpt = -fwarn-unused-matches -fwarn-unused-binds -fwarn-unused-imports -fno-warn-overlapping-patterns -XRecordWildCards -XNamedFieldPuns -XFlexibleContexts -XMultiParamTypeClasses -XUndecidableInstances -XTypeSynonymInstances -XFlexibleInstances -fcontext-stack=30 as it is written there in README.txt. README.txt explains which two instances are wrongly resolved -- as I expect. In ghc-7.8.2 they are resolved in a correct way (and there is a different pragma syntax). I conclude this from running the test in docon-2.12. Am I missing something? Please, advise, ------ Sergei

2 6

ANNOUNCE: GHC 7.10.2 Release Candidate 1
by Austin Seipp 14 Jun '15

14 Jun '15

We are pleased to announce the first release candidate for GHC 7.10.2: https://downloads.haskell.org/~ghc/7.10.2-rc1 https://downloads.haskell.org/~ghc/7.10.2-rc1/docs/html/ This includes the source tarball and bindists for Windows, Mac OS X, and Debian Linux. FreeBSD and Solaris binaries will follow soon. These binaries and tarballs have an accompanying SHA256SUMS file signed by my GPG key id (0x3B58D86F). We plan to make the 7.10.2 final release at the end of this coming week - so please test as much as possible; bugs are much cheaper if we find them before the release! -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

cannot build 'vector' with profiling
by Ranjit Jhala 11 Jun '15

11 Jun '15

Hi all, I cannot build 'vector' (or 'cmdargs') with profiling on. specifically when I run: $ cabal install --enable-executable-profiling --enable-library-profiling --ghc-options="-O2 -rtsopts -prof -auto-all -caf-all" vector I get the message: Perhaps you haven't installed the "p_dyn" libraries for package ‛integer-gmp’ https://ghc.haskell.org/trac/ghc/ticket/8677 Per some advice I tried to add the '--disable-shared' $ cabal install --disable-shared --enable-executable-profiling --enable-library-profiling --ghc-options="-O2 -rtsopts -prof -auto-all -caf-all" vector but then I get this: Loading package primitive-0.6 ... <command line>: can't load .so/.DLL for: libHSprimitive-0.6.dylib (dlopen(libHSprimitive-0.6.dylib, 9): image not found) Any idea whats going on or for any work arounds? Pretty stumped! Thanks in advance! Ranjit.

3 10

7.10 branch
by Simon Peyton Jones 11 Jun '15

11 Jun '15

Austin I'm getting these validation failures on the 7.10 branch. Are you? This is on Linux. Simon Unexpected failures: driver T8959a [bad stderr] (normal) ghci/scripts T9878b [bad stderr] (ghci) th T10279 [stderr mismatch] (normal) Unexpected stat failures: perf/should_run T4830 [stat not good enough] (normal) perf/should_run T7436 [stat not good enough] (normal)

1 0

Re: [Haskell-cafe] The evil GADTs extension in ghci 7.8.4 (maybe in other versions too?)
by Edward Z. Yang 10 Jun '15

10 Jun '15

This is because -XGADTs implies -XMonoLocalBinds. Edward Excerpts from Ki Yung Ahn's message of 2015-06-04 20:29:50 -0700: > \y -> let x = (\z -> y) in x x > > is a perfectly fine there whose type is a -> a. > (1) With no options, ghci infers its type correctly. > (2) However, with -XGADTs, type check fails and raises occurs check. > (3) We can remedy this by supplying some additional options > (4) Howver, if you put -XGADTs option at the end, it fails again :( > > > kyagrd@kyahp:~$ ghci > GHCi, version 7.8.4: http://www.haskell.org/ghc/ :? for help > Loading package ghc-prim ... linking ... done. > Loading package integer-gmp ... linking ... done. > Loading package base ... linking ... done. > Prelude> :t \y -> let x = (\z -> y) in x x > \y -> let x = (\z -> y) in x x :: t -> t > Prelude> :q > Leaving GHCi. > > > kyagrd@kyahp:~$ ghci -XGADTs > GHCi, version 7.8.4: http://www.haskell.org/ghc/ :? for help > Loading package ghc-prim ... linking ... done. > Loading package integer-gmp ... linking ... done. > Loading package base ... linking ... done. > Prelude> :t \y -> let x = (\z -> y) in x x > > <interactive>:1:30: > Occurs check: cannot construct the infinite type: t0 ~ t0 -> t > Relevant bindings include > x :: t0 -> t (bound at <interactive>:1:11) > y :: t (bound at <interactive>:1:2) > In the first argument of ‘x’, namely ‘x’ > In the expression: x x > Prelude> :q > Leaving GHCi. > > > ~$ ghci -XGADTs -XNoMonoLocalBinds -XNoMonomorphismRestriction > GHCi, version 7.8.4: http://www.haskell.org/ghc/ :? for help > Loading package ghc-prim ... linking ... done. > Loading package integer-gmp ... linking ... done. > Loading package base ... linking ... done. > Prelude> :t \y -> let x = (\z -> y) in x x > \y -> let x = (\z -> y) in x x :: t -> t > Prelude> :q > Leaving GHCi. > > > ~$ ghci -XNoMonoLocalBinds -XNoMonomorphismRestriction -XGADTs > GHCi, version 7.8.4: http://www.haskell.org/ghc/ :? for help > Loading package ghc-prim ... linking ... done. > Loading package integer-gmp ... linking ... done. > Loading package base ... linking ... done. > Prelude> :t \y -> let x = (\z -> y) in x x > > <interactive>:1:30: > Occurs check: cannot construct the infinite type: t0 ~ t0 -> t > Relevant bindings include > x :: t0 -> t (bound at <interactive>:1:11) > y :: t (bound at <interactive>:1:2) > In the first argument of ‘x’, namely ‘x’ >

3 3

Closed Type Families: type checking dumbness? [was: separate instance groups]
by AntC 08 Jun '15

08 Jun '15

> From: AntC > Date: 2015-06-04 22:39:25 GMT > > Take the standard example for partial overlaps. > Suppose I have a class: ... > I'm also getting (in more complex examples) > GHC complaining it can't infer the types > for the result of f. > So now I'm having to put type equality > constraints on the class instances, > to assure it that F comes up with > the right type. In a reduced example, I'm still getting poor type checking. This is GHC 7.8.3. This seems so dumb, I'm suspecting a defect, It's similar to but much more glaring than: https://ghc.haskell.org/trac/ghc/ticket/10227 https://ghc.haskell.org/trac/ghc/ticket/9918 {-# LANGUAGE TypeFamilies, FlexibleInstances #-} module ClosedTypeFamily where data Foo b c = Foo b c deriving (Eq, Read, Show) type family F a where F (Foo Int c) = Int -- Foo Int is first instance F (Foo b Char) = Char class C a where f :: a -> F a instance C (Foo Int c) where -- compiles OK f (Foo x _) = x instance (F (Foo b Char) ~ Char) => C (Foo b Char) where f (Foo _ y) = y needs the eq constraint. Without it, GHC complains: Couldn't match expected type ‘F (Foo b Char)’ with actual type ‘Char’ Relevant bindings include f :: Foo b Char -> F (Foo b Char) In the expression: y In an equation for ‘f’: f (Foo _ y) = y Note that if I change the sequence of the family instances for F, then GHC instead complains about the class instance for (Foo Int c). OK these are overlapping class instances. But GHC's usual behaviour (without closed type families) is to postpone complaining until and unless a usage (Foo Int Char) actually turns up. BTW if I put a first family instance F (Foo Int Char) = Int to explicitly catch the overlap, then GHC complains about **both** class instances. Reminder [to Richard] I need not only types but also terms. AntC

4 6

Closed Type Families: separate instance groups?
by AntC 04 Jun '15

04 Jun '15

Currently (GHC 7.8.3) the only form for Closed Type Families is: type family F a where ... -- list your instances here (This was considered a common use case -- for example in HList to put the type-matching instance with the non-matching, and that would be total coverage; rather than needing a type family decl and an instance decl with the instance head same as family. That was an optimisation over ...) Way back the design was more like this: type family F a type instance F (Foo b c) where F (Foo Int c) = ... F (Foo b Char) = ... type instance F (Bar e f g) where F (Bar Int f g) = ... The idea was that the separate instance groups must have non-overlapping heads. This is handy if Foo, Bar, etc are declared in separate places/modules. You can put the instances with the data decl. And quite possibly the family decl is in an imported/library module you don't want to touch. Is this separate instance group idea still a gleam in someone's eye? If not, is there some deep theoretical reason against? AntC

3 4

HEADS UP: Final call for 7.10.2 is soon
by Austin Seipp 03 Jun '15

03 Jun '15

Hi *, I've just finished merging all the latest patches for GHC 7.10.2 into the STABLE branch. All in all, we've fixed a lot of bugs (over 80 tickets closed)! So, we'll probably be doing a 7.10.2 release here in a few weeks. The tentative plan was around the 14th, although it's not set in stone. (At worst, it would be pushed from the 14th to the 21st). With that in mind, if I could quickly direct your attention to the GHC bug tracker and the status page[1] - it would be really helpful if you check if the things you want are fixed! Specifically, if you want something fixed for the 7.10.2 release: - Make sure there is a ticket. It really needs to exist or we'll just forget! - If your bug is critical, please explain why! We really want to kill showstoppers ASAP, because bugs are much cheaper to fix early. If that's the case we can bump the priority if it's necessary to make things clear. - Set the milestone to 7.10.2. It'll automatically appear on the status page. That should be it - we'll be monitoring the status page regularly to keep track of new things. The current bug list is pretty small - we may move some of them out, or fix several more. So just try to let us know. As a sidenote, I'm quite happy with this release - it's fixed dozens of tricky bugs, improved some nasty corner cases in compiler performance, and overall seems like it will be high quality. Thanks to everyone who submitted patches! I'll send out another email next week as another reminder. [1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.2 -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

5 4

GHC Weekly News - 2015/06/03
by Austin Seipp 03 Jun '15

03 Jun '15

(This post is available online at https://ghc.haskell.org/trac/ghc/blog/weekly20150603) Hi *, It's that time once again - to get some info on what's happening in the world of GHC! It's been a quiet few weeks as a UK Holiday punted one of GHC HQ's meetings off, and this week we were only partially there. The main point of discussion was 7.10.2, and continuing work on compiler performance. The good news is, the past few weeks have seen good work on both these fronts! == 7.10.2 status == 7.10.2 is swimming along very nicely - the [https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.2 status page] shows the current set of tickets we've fixed and plan on fixing. Not much has changed from last time, except we've fixed even more bugs! We're currently sitting at about 85 bugs fixed, some of them pretty important - code generation bugs, compiler performance fixes, some RTS and event manager work. Your author is actually quite happy with what GHC 7.10.2 looks like, at this rate. == List chatter == - Austin Seipp announced that GHC 7.10.2 will be release soon, and developers/users should get bugs they want fixed reported to us ASAP so we can do something. https://mail.haskell.org/pipermail/ghc-devs/2015-June/009150.html - Mark Lentczner announced a Haskell Platform alpha featuring GHC 7.10.2 https://mail.haskell.org/pipermail/ghc-devs/2015-June/009128.html - Facundo Dominguez asks: sometimes we want to create a `static` pointer in a function with a local definition, how can we do that? The current problem is the desugarer gets in the way and current approaches are currently rejected, but Facundo has some ideas/questions about a fix. https://mail.haskell.org/pipermail/ghc-devs/2015-May/009110.html - David Macek has made great progress on getting native MSYS2 packages for windows working - which should be a great boon to all our Windows users! https://mail.haskell.org/pipermail/ghc-devs/2015-May/009089.html - Joachim Breitner announced the new GHC performance dashboard, which can be used to track all of GHC's performance-based tests over time. Whoohoo! https://mail.haskell.org/pipermail/ghc-devs/2015-May/009032.html - Joachim Breitner asked: is there a way to programmatically 'Raise a Concern' on a Phabricator commit? With the new https://perf.haskell.org/ghc/ work, it'd be nice if regressions could be automatically flagged. The current problem is there is no API endpoint, but one can be built. https://mail.haskell.org/pipermail/ghc-devs/2015-June/009128.html - Adam Gundry asked ghc-devs about some input on changes to the new typechecker plugins API. After some discussion and elbow grease, the new changes have already landed in HEAD and will be in 7.12.1. https://mail.haskell.org/pipermail/ghc-devs/2015-May/009097.html == Noteworthy commits == - Commit 45d9a15c4b85a2ed89579106bdafd84accf2cb39 - Fix a huge space leak in the mighty simplifier - Commit c89bd681d34d3339771ebdde8aa468b1d9ab042b - Fix quadratic behavior in `tidyOccName` - Commit b03f074fd51adfb9bc4f5275294712ee62741aed - ghci: Allow `:back` and `:forward` to take counts - Commit 8e4dc8fb63b8d3bfee485c1c830776f3ed704f4d - Greatly speed up `nativeCodeGen/seqBlocks` - Commit c256357242ee2dd282fd0516260edccbb7617244 - Speed up `elimCommonBlocks` by grouping blocks also by outgoing labels - Commit f5188f3acd73a07b648924a58b9882c2d0a3dbcb - Fix weird behavior of `-ignore-dot-ghci` and `-ghci-script` - Commit 4fffbc34c024231c3c9fac7a2134896cc09c7fb7 - New handling of overlapping instances in Safe Haskell - Commit f16ddcee0c64a92ab911a7841a8cf64e3ac671fd - Support stage 1 Template Haskell (non-quasi) quotes, fixes #10382 - Commit cf7573b8207bbb17c58612f3345e0b17d74cfb58 - More accurate allocation stats for `:set -s` == Closed tickets == #10407, #10408, #10177, #10359, #10403, #10248, #9579, #10415, #10419, #10427, #10429, #10397, #10422, #10335, #10366, #10110, #10397, #10349, #10244, #8555, #8799, #9131, #10396, #10354, #10278, #9899, #3533, #9950, #10092, #9950, #10430, #9682, #9584, #10446, #10410, #10298, #10449, #10399, #7695, #10261, #8292, #10360, #10126, #10317, #10101, #10322, #10313, #10471, #10473, #7170, #10473, #10423, #10466, #8695, #10461, #10052, #10370, #10425, #10452, #10474, -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

Ambiguity check and type families
by Wolfgang Jeltsch 02 Jun '15

02 Jun '15

Hi, the following (contrived) code is accepted by GHC 7.8.3, but not 7.10.1: > {-# LANGUAGE TypeFamilies #-} > > type family F a :: * > > type family G b :: * > > x :: G (F a) ~ a => F a > x = undefined GHC 7.10.1 reports: > Could not deduce (F a0 ~ F a) > from the context (G (F a) ~ a) > bound by the type signature for x :: (G (F a) ~ a) => F a > at Test.hs:7:6-23 > NB: ‘F’ is a type function, and may not be injective > The type variable ‘a0’ is ambiguous > In the ambiguity check for the type signature for ‘x’: > x :: forall a. (G (F a) ~ a) => F a > To defer the ambiguity check to use sites, enable AllowAmbiguousTypes > In the type signature for ‘x’: x :: G (F a) ~ a => F a At a first look, this complaint seems reasonable, and I have already wondered why GHC 7.8.3 actually accepts the above code. >From an intuitive standpoint, however, the code seems actually acceptable to me. While it is true that type families are generally not injective, it is possible to derive the type a from F a by applying G. It would great if this code would be accepted by GHC again and if there was a workaround to make it work with GHC 7.10.1. At the moment, this change in the type checker from 7.8.3 to 7.10.1 breaks the incremental-computing package in a rather fundamental way. All the best, Wolfgang

3 3