- Glasgow-haskell-users

TH Show instance not working.
by David Banas 20 Aug '17

20 Aug '17

Hi all, Does anyone know why this code: module Language.P4.UtilTest where import Language.P4.Util (mkShow) data Dummy = Bogus Char | Nonsense Int $(mkShow ''Dummy) is producing this error: Davids-Air-2:P4 dbanas$ stack ghc -- UtilTest.hs -ddump-splices [1 of 1] Compiling Language.P4.UtilTest ( UtilTest.hs, UtilTest.o ) UtilTest.hs:24:3-16: Splicing declarations mkShow ''Dummy ======> instance Show Dummy where show (Bogus x) = show x show (Nonsense x) = show x UtilTest.hs:24:3: error: Conflicting definitions for ‘show’ Bound at: UtilTest.hs:24:3-16 UtilTest.hs:24:3-16 | 24 | $(mkShow ''Dummy) | ^^^^^^^^^^^^^^ ? The TH splice expansion looks correct to me. If I comment out the second constructor (Nonsense Int), the code compiles without error. Thanks, -db

2 2

8.2.1 changes to iface/FlagChecker.hs
by Evan Laforge 03 Aug '17

03 Aug '17

My program uses the GHC API to provide a REPL, and upgrading to 8.2.1 broke that... well, just made it really slow. Where it used to quickly load the compiled files, it now wants to recompile everything as bytecode which makes 1s startup time go to 1m. The reason was it now thinks flags have changed. I tracked it down to changes in FlagChecker.hs, documented with https://ghc.haskell.org/trac/ghc/ticket/11798 and https://ghc.haskell.org/trac/ghc/ticket/10923, which add -fhpc and -O to the tracked flags. -fhpc means loading tests in ghci can never work, because ghci rejects the -fhpc flag, and likewise -O means ghci can never load optimized files for the same reason. It seems like the easiest solution might be to just have ghci not reject -fhpc and -O. Of course we could also revert those changes, but they're justified in the trac tickets. Of course this means I'm loading optimized code together with bytecode compiled code and maybe that's a bad thing (or for tests, -fhpc with non-hpc). But I've been doing this for something like 7 years and it's been fine. Unrelatedly, I was hoping compiles would get faster, but they seem a bit slower, from around 3m20s to around 4m :( I can track down per-file timing changes if it would be interesting to someone. Also thanks to whoever put trac tickets in the comments, it makes it really easy to find out why a change was made.

2 2

GHC release timing and future build infrastructure
by Ben Gamari 01 Aug '17

01 Aug '17

Hello everyone, I just posted a pair of posts on the GHC blog [1,2] laying out some thoughts on the GHC release cycle timing [1] and how this relates to the in-progress Jenkins build infrastructure [2]. When you have a some time feel free to give them a read and comment (either here or on the Reddit thread [3]). Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/blog/2017-release-schedule [2] https://ghc.haskell.org/trac/ghc/blog/jenkins-ci [3] https://www.reddit.com/r/haskell/comments/6qt0iv/ghc_blog_reflections_on_gh…

2 1

[ANNOUNCE] GHC 8.2.1 available
by Ben Gamari 27 Jul '17

27 Jul '17

=============================================== The Glasgow Haskell Compiler -- version 8.2.1 =============================================== The GHC developers are very happy to announce the long-awaited 8.2.1 release of Glasgow Haskell Compiler. Binary and source distributions can be found at https://downloads.haskell.org/~ghc/8.2.1/ This is the second release in the 8.0 series. As such, the focus of this release is performance, stability, and consolidation. Consequently numerous cleanups can be seen throughout the compiler including, * Significant improvements in compiler performance * More robust support for levity polymorphism * Reliable DWARF debugging information * Improved runtime system performance on NUMA systems * Retooling of the cost-center profiler, including support for live streaming of profile data via the GHC event log * Interface file determinism * More robust treatment of join points, enabling significantly better code generation in many cases * Numerous improvements in robustness on Windows * and the resolution of over 500 other tickets In addition, there are a number of new features, * A new, more type-safe type reflection mechanism * The long-awaited Backpack module system * Deriving strategies to disambiguate between GHC's various instance deriving mechanisms * Unboxed sum types, for efficient unpacked representation of sum data types * Compact regions, allowing better control over garbage collection in the presence of large heaps containing many long-lived objects. * Colorful messages and caret diagnostics for more legible errors A more thorough list of the changes in this release can be found in the release notes, https://haskell.org/ghc/docs/8.2.1/docs/html/users_guide/8.2.1-notes.html There are a few changes in release-engineering that should be noted, * Binary distributions for 32-bit CentOS 6.7 have been dropped. Moreover, there are no dedicated CentOS 7.0 distributions as CentOS 7 can use can use Debian 8 binaries. If you would like us to continue to produce 32-bit CentOS 6.7 distributions please let us know. * GHC HQ now builds FreeBSD and OpenBSD distributions for amd64; this comes after many years of these distributions being faithfully provided by Karel Gardas and Pali Gabor Janos, who we should heartily thank for their contributions. GHC HQ building these distributions ourselves will allow us to more quickly ship distributions to users by eliminating the need for a long lag time between source release availability and having all binary distributions available. * There is a technology-preview of an AArch64 Linux binary distribution, as well as an ARM Linux build. AArch64 support is quite preliminary but should be stable in 8.4 thanks to further linker fixes by Moritz Angerman. ARM should be stable. * GHC now tries to use the gold and lld linkers by default. These linkers are significantly faster than the BFD linker implementation that most Linux distributions use by default. If gold or lld are not available GHC will use the system's default linker. GHC can be forced to use the default linker by passing --disable-ld-override to configure. This release has been the result of over a year of hard work by over 150 code contributors. Thanks to everyone who has helped in writing patches, testing, reporting bugs, and offering feedback over the last year. This release cycle was admittedly quite drawn out, significantly longer than expected or desired. While we are confident that the result is worth the wait, we have been steadily working on infrastructure which should help shrink future release cycles and give us better testing between releases. More details on this coming soon. As always, let us know if you encounter trouble. How to get it ~~~~~~~~~~~~~ The easy way is to go to the web page, which should be self-explanatory: http://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. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~~~~~~~~~ Haskell is a standard 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 http://www.haskell.org/ghc/ GHC developers' home page http://ghc.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, is here: http://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: http://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 run by Trac: http://ghc.haskell.org/trac/ghc/ Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users http://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 Some GHC developers hang out on #haskell on IRC, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug

4 6

Trouble with injective type families
by Wolfgang Jeltsch 15 Jul '17

15 Jul '17

Hi! Injective type families as supported by GHC 8.0.1 do not behave like I would expect them to behave from my intuitive understanding. Let us consider the following example: > {-# LANGUAGE RankNTypes, TypeFamilyDependencies #-} > > class C a where > > type T a = b | b -> a > > instance C Bool where > > type T Bool = Int > > type X b = forall a . T a ~ b => a > > x :: X Int > x = False I would expect this code to be accepted. However, I get the following error message: > A.hs:14:5: error: > • Could not deduce: a ~ Bool > from the context: T a ~ Int > bound by the type signature for: > x :: T a ~ Int => a > at A.hs:13:1-10 > ‘a’ is a rigid type variable bound by > the type signature for: > x :: forall a. T a ~ Int => a > at A.hs:11:19 > • In the expression: False > In an equation for ‘x’: x = False > • Relevant bindings include x :: a (bound at A.hs:14:1) This is strange, since injectivity should exactly make it possible to deduce a ~ Bool from T a ~ Int. Another example is this: > {-# LANGUAGE GADTs, TypeFamilyDependencies #-} > > class C a where > > type T a = b | b -> a > > instance C Bool where > > type T Bool = Int > > data G b where > > G :: Eq a => a -> G (T a) > > instance Eq (G b) where > > G a1 == G a2 = a1 == a2a I would also expect this code to be accepted. However, I get the following error message: > B.hs:17:26: error: > • Could not deduce: a1 ~ a > from the context: (b ~ T a, Eq a) > bound by a pattern with constructor: > G :: forall a. Eq a => a -> G (T a), > in an equation for ‘==’ > at B.hs:17:5-8 > or from: (b ~ T a1, Eq a1) > bound by a pattern with constructor: > G :: forall a. Eq a => a -> G (T a), > in an equation for ‘==’ > at B.hs:17:13-16 > ‘a1’ is a rigid type variable bound by > a pattern with constructor: G :: forall a. Eq a => a -> G (T a), > in an equation for ‘==’ > at B.hs:17:13 > ‘a’ is a rigid type variable bound by > a pattern with constructor: G :: forall a. Eq a => a -> G (T a), > in an equation for ‘==’ > at B.hs:17:5 > • In the second argument of ‘(==)’, namely ‘a2’ > In the expression: a1 == a2 > In an equation for ‘==’: (G a1) == (G a2) = a1 == a2 > • Relevant bindings include > a2 :: a1 (bound at B.hs:17:15) > a1 :: a (bound at B.hs:17:7) If b ~ T a and b ~ T a1, then T a ~ T a1 and subsequently a ~ a1, because of injectivity. Unfortunately, GHC does not join the two contexts (b ~ T a, Eq a) and (b ~ T a1, Eq a1). Are these behaviors really intended, or are these bugs showing up? All the best, Wolfgang

4 4

Heterogeneous equality
by Wolfgang Jeltsch 07 Jul '17

07 Jul '17

Hi! The base package contains the module Data.Type.Equality, which contains the type (:~:) for homogeneous equality. I was a bit surprised that there is no type for heterogeneous equality there. Is there such a type somewhere else in the standard library? I tried to define a type for heterogeneous equality myself as follows: > {-# LANGUAGE GADTs, PolyKinds, TypeOperators #-} > > data a :~~: b where > > HRefl :: a :~~: a To my surprise, the kind of (:~~:) defined this way is k -> k -> *, not k -> l -> *. Why is this? Apparently, the latter, more general, kind is possible, since we can define (:~~:) :: k -> l -> * as follows: > {-# LANGUAGE GADTs, PolyKinds, TypeOperators #-} > > data (a :: k) :~~: (b :: l) where > > HRefl :: a :~~: a All the best, Wolfgang

2 1

Re: Trouble with injective type families
by Anthony Clayden 07 Jul '17

07 Jul '17

> On Wed Jul 5 14:16:10 UTC 2017, Richard Eisenberg wrote: > I'd like to add that the reason we never extended System FC > with support for injectivity is that the proof of soundness > of doing so has remained elusive. Thank you Richard, Simon. IIRC the original FDs through CHRs paper did think it sound to allow given `C a b1` and `C a b2` conclude `b1 ~ b2` under a FunDep `a -> b`. (I think that was also the case in Mark Jones' original paper on FunDeps.) (See Iavor's comments on Trac #10675, for example.) I know GHC's current FunDep inference is lax, because there's good reasons to want 'wiggle room' with FunDep (in)consistency. I'm suggesting we could tighten that consistency check; then we might make make FD inference stronger(?) https://github.com/ghc-proposals/ghc-proposals/pull/56#issuecomment-3129745… AntC >> Am Mittwoch, den 05.07.2017, 06:45 +0000 schrieb Simon Peyton Jones: >> Functional dependencies and type-family dependencies only induce extra >> "improvement" constraints, not evidence. For example >> >> class C a b | a -> b where foo :: a -> b >> instance C Bool Int where ... >> >> f :: C Bool b => b -> Int >> f x = x -- Rejected >> >> Does the fundep on 'b' allow us to deduce (b ~ Int), GADT-like, in the >> body of 'f', and hence accept the definition. No, it does not. Think >> of the translation into System F. We get >> >> f = /\b \(d :: C Bool b). \(x::b). x |> ??? >> >> What evidence can I used to cast 'x' by to get it >> from type 'b' to Int? >> >> Rather, fundeps resolve ambiguity. Consider >> >> g x = foo True + x >> >> The call to 'foo True' gives rise to a "wanted" constraint (C Bool >> beta), where beta is a fresh unification variable. Then by the fundep >> we get an "improvement" constraint (also "wanted") (beta ~ Int). So we >> can infer g :: Int -> Int. >> >> >> In your example we have >> >> x :: forall a b. (T Int ~ b) => a >> x = False >> >> Think of the System F translation: >> >> x = /\a b. \(d :: T Int ~ b). False |> ?? >> >> Again, what evidence can we use to cast False to 'a'. >> >> >> In short, fundeps and type family dependencies only add extra >> unification constraints, which may help to resolve ambiguous >> types. They dont provide evidence. That's not to say that they >> couldn't. But you'd need to extend System FC, GHC's core language, to >> do so. >> >> Simon >> >> >>> >>> -----Original Message----- >>> From: Glasgow-haskell-users [mailto:glasgow-haskell-users- >>> bounces at haskell.org] On Behalf Of Wolfgang Jeltsch >>> Sent: 05 July 2017 01:21 >>> To: glasgow-haskell-users at haskell.org >>> Subject: Trouble with injective type families >>> >>> Hi! >>> >>> Injective type families as supported by GHC 8.0.1 do not behave like >>> I >>> would expect them to behave from my intuitive understanding. >>> >>> Let us consider the following example: >>> >>>> >>>> {-# LANGUAGE RankNTypes, TypeFamilyDependencies #-} >>>> >>>> class C a where >>>> >>>> type T a = b | b -> a >>>> >>>> instance C Bool where >>>> >>>> type T Bool = Int >>>> >>>> type X b = forall a . T a ~ b => a >>>> >>>> x :: X Int >>>> x = False >>> I would expect this code to be accepted. However, I get the >>> following >>> error message: >>> >>>> >>>> A.hs:14:5: error: >>>> Could not deduce: a ~ Bool >>>> from the context: T a ~ Int >>>> bound by the type signature for: >>>> x :: T a ~ Int => a >>>> at A.hs:13:1-10 >>>> a is a rigid type variable bound by >>>> the type signature for: >>>> x :: forall a. T a ~ Int => a >>>> at A.hs:11:19 >>>> In the expression: False >>>> In an equation for x: x = False >>>> Relevant bindings include x :: a (bound at A.hs:14:1) >>> This is strange, since injectivity should exactly make it possible >>> to >>> deduce a ~ Bool from T a ~ Int. >>> >>> Another example is this: >>> >>>> >>>> {-# LANGUAGE GADTs, TypeFamilyDependencies #-} >>>> >>>> class C a where >>>> >>>> type T a = b | b -> a >>>> >>>> instance C Bool where >>>> >>>> type T Bool = Int >>>> >>>> data G b where >>>> >>>> G :: Eq a => a -> G (T a) >>>> >>>> instance Eq (G b) where >>>> >>>> G a1 == G a2 = a1 == a2a >>> I would also expect this code to be accepted. However, I get the >>> following error message: >>> >>>> >>>> B.hs:17:26: error: >>>> Could not deduce: a1 ~ a >>>> from the context: (b ~ T a, Eq a) >>>> bound by a pattern with constructor: >>>> G :: forall a. Eq a => a -> G (T a), >>>> in an equation for == >>>> at B.hs:17:5-8 >>>> or from: (b ~ T a1, Eq a1) >>>> bound by a pattern with constructor: >>>> G :: forall a. Eq a => a -> G (T a), >>>> in an equation for == >>>> at B.hs:17:13-16 >>>> a1 is a rigid type variable bound by >>>> a pattern with constructor: G :: forall a. Eq a => a -> G >>>> (T >>>> a), >>>> in an equation for == >>>> at B.hs:17:13 >>>> a is a rigid type variable bound by >>>> a pattern with constructor: G :: forall a. Eq a => a -> G >>>> (T >>>> a), >>>> in an equation for == >>>> at B.hs:17:5 >>>> In the second argument of (==), namely a2 >>>> In the expression: a1 == a2 >>>> In an equation for ==: (G a1) == (G a2) = a1 == a2 >>>> Relevant bindings include >>>> a2 :: a1 (bound at B.hs:17:15) >>>> a1 :: a (bound at B.hs:17:7) >>> If b ~ T a and b ~ T a1, then T a ~ T a1 and subsequently a ~ a1, >>> because >>> of injectivity. Unfortunately, GHC does not join the two contexts (b >>> ~ T >>> a, Eq a) and (b ~ T a1, Eq a1). >>> >>> Are these behaviors really intended, or are these bugs showing up? >>>

1 0

Contradictions about DeriveDataTypeable in the manual?
by Chris Martin 26 Jun '17

26 Jun '17

Exhibit A: > With -XDeriveDataTypeable, you can derive instances of the class Data, defined in Data.Data. See "Deriving Typeable instances" for deriving Typeable. Exhibit B: > -XDeriveDataTypeable > Enable automatic deriving of instances for the Typeable typeclass Exhibit C: > Derived instances of Typeable are ignored, and may be reported as an error in a later version of the compiler. ---------------- A and B seem contradictory: Is this extension for deriving Data, or for deriving Typeable? B and C seem... not technically contradictory, but why is there an extension that enables the deriving of instances that will just be ignored? Is this extension meant to be deprecated? >From experimentation, it seems like all types automatically get Typeable instances whether you declare it or not. Is that accurate?

2 2

Proposal: Instance apartness guards
by Anthony Clayden 24 Jun '17

24 Jun '17

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

Untouchable type variables
by Wolfgang Jeltsch 19 Jun '17

19 Jun '17

Hi! Today I encountered for the first time the notion of an “untouchable” type variable. I have no clue what this is supposed to mean. A minimal example that exposes my problem is the following: > {-# LANGUAGE Rank2Types, TypeFamilies #-} > > import GHC.Exts (Constraint) > > type family F a b :: Constraint > > data T b c = T > > f :: (forall b . F a b => T b c) -> a > f _ = undefined This results in the following error message from GHC 8.0.1: > Untouchable.hs:9:6: error: > • Couldn't match type ‘c0’ with ‘c’ > ‘c0’ is untouchable > inside the constraints: F a b > bound by the type signature for: > f :: F a b => T b c0 > at Untouchable.hs:9:6-37 > ‘c’ is a rigid type variable bound by > the type signature for: > f :: forall a c. (forall b. F a b => T b c) -> a > at Untouchable.hs:9:6 > Expected type: T b c0 > Actual type: T b c > • In the ambiguity check for ‘f’ > To defer the ambiguity check to use sites, enable AllowAmbiguousTypes > In the type signature: > f :: (forall b. F a b => T b c) -> a I have no idea what the problem is. The type of f looks fine to me. The type variable c should be universally quantified at the outermost level. Why does the type checker even introduce a type variable c0? All the best, Wolfgang

4 4