May 2017 - ghc-tickets

[GHC] #13157: Opportunity to improve case-of-case
by GHC 24 Nov '17

24 Nov '17

#13157: Opportunity to improve case-of-case -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider this code {{{ f g x = (case g x of True -> not False -> id) `seq` True }}} With GHC 8 (and -O) we get this Core {{{ f = \ (@ t_a1rk) (g_aqD :: t -> Bool) (x_aqE :: t) -> case case g_aqD x_aqE of { False -> id @ Bool; True -> not } of { __DEFAULT -> GHC.Types.True } }}} This is obviously bad. The reasoning is in the long, complicated `Note [Single-alternative cases]` in `Simplify.hs`. Happily with join points the entire Note becomes unnecessary; we can delete the special case that this Note describes, and the Note itself. Result: simpler compiler, and more optimal code. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13157> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12159: Record-like GADTs with repeated fields (of same type) rejected
by GHC 22 Nov '17

22 Nov '17

#12159: Record-like GADTs with repeated fields (of same type) rejected -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I came across a curious bug with record-like GADTs and repeated fields. Consider following code: {{{#!hs {-# LANGUAGE GADTs #-} data Foo p where Bar :: { quux' :: Bool } -> Foo Char Baz :: { quux'' :: Bool } -> Foo Int quux :: Foo p -> Bool quux (Bar q) = q quux (Baz q) = q quuxSetter :: Foo p -> Bool -> Foo p quuxSetter old@Bar{} q = old{quux' = q} quuxSetter old@Baz{} q = old{quux'' = q} }}} This compiles and all is fine. *But* GHC is supposed to create the nice `quux` and `quuxSetter` accessors for me, right? So, let's try: {{{#!hs data Foo p where Bar :: { quux :: Bool } -> Foo Char Baz :: { quux :: Bool } -> Foo Int }}} It does not compile! Instead I get: {{{ T12159.hs:3:1: error: Constructors Bar and Baz have a common field quux , but have different result types In the data type declaration for Foo Failed, modules loaded: none. }}} This is not very polite :-) It should simply create the accessors like I did above. It obviously can be done! Testcase is attached. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12159> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #11721: GADT-syntax data constructors don't work well with TypeApplications
by GHC 20 Nov '17

20 Nov '17

#11721: GADT-syntax data constructors don't work well with TypeApplications -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple TypeApplications | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider {{{ data X a where MkX :: b -> Proxy a -> X a }}} According to the rules around specified vs. generalized variables around `TypeApplications`, the type of `MkX` should be {{{ MkX :: forall {k} (b :: *) (a :: k). b -> Proxy a -> X a }}} A few things to note: * The `k` isn't available for `TypeApplications` (that's why it's in braces), because it is not user-written. * The `b` is quantified before the `a`, because `b` comes before `a` in the user-written type signature for `MkX`. Both of these bullets are currently violated. GHCi reports `MkX`'s type as {{{ MkX :: forall k (a :: k) b. b -> Proxy a -> X a }}} It turns out that this is a hard to fix. The problem is that GHC expects data constructors to have their universal variables followed by their existential variables, always. And yet that's violated in the desired type for `MkX`. Furthermore, given the way that GHC deals with GADT return types ("rejigging", in technical parlance), it's inconvenient to get the specified/generalized distinction correct. Given time constraints, I'm afraid fixing this all won't make it for 8.0. Happily, there is are easy-to-articulate rules governing GHC's current (wrong) behavior. In a GADT-syntax data constructor: * All kind and type variables are considered specified and available for visible type application. * Universal variables always come first, in precisely the order they appear in the tycon. Note that universals that are constrained by a GADT return type are missing from the datacon. * Existential variables come next. Their order is determined by a user- written `forall`; or, if there is none, by taking the left-to-right order in the datacon's type and doing a stable topological sort. (This stable topological sort step is the same as for other user-written type signatures.) Despite the existence of these rules, it would still be better not to have special rules for GADT-syntax data constructors. This ticket is intended to capture that eventual goal. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11721> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #9118: Can't eta-reduce representational coercions
by GHC 19 Nov '17

19 Nov '17

#9118: Can't eta-reduce representational coercions ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- When I say {{{ import Data.Type.Coercion import Data.Coerce import Data.Proxy eta2 :: Coercible (f a) (g a) => Proxy a -> Coercion f g eta2 _ = Coercion }}} I get {{{ Could not coerce from ‘f’ to ‘g’ because ‘f’ and ‘g’ are different types. arising from a use of ‘Coercion’ from the context (Coercible (f a) (g a)) bound by the type signature for eta2 :: Coercible (f a) (g a) => Proxy a -> Coercion f g at /Users/rae/temp/Roles.hs:5:9-56 In the expression: Coercion In an equation for ‘eta2’: eta2 _ = Coercion }}} Unlike the case for #9116, this one is ''not'' expressible in Core. (At least, I don't see a way to do it.) So, to do this, we would have to update Core and then update the constraint solver. I ''do'' think this would be type safe. But, I also think it's reasonable to wait for someone with a real use case to shout before doing this. The only use case I have is to be able to do this: {{{ -- says that a's parameter is representational class Rep (a :: k1 -> k2) where co :: Coercible x y => Coercible (a x) (a x) instance Rep f => Rep (Compose f) where ... }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9118> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #11392: Decide and document how semicolons are supposed to work in GHCi
by GHC 19 Nov '17

19 Nov '17

#11392: Decide and document how semicolons are supposed to work in GHCi -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: GHCi | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #10663 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently there is a fair bit of confusion surrounding the intended function of semicolons in GHCi (see #10663 and Phab:D1726), * the users guide doesn't discuss the matter at all * sometimes the content after semicolons work as expected {{{ λ> let x=2; y=5 λ> x+y 7 }}} * other times it is silently ignored (see #10663), {{{ λ> import Data.List; 684 λ> }}} * other times it works but the parser state is subtly wrong, resulting in (arguably) incorrect line numbers later in the session, {{{ λ> data Infix a b = a :@: b; infixl 4 :@: λ> a <interactive>:3:1: error: Variable not in scope: a }}} * some times the only way to accomplish a given task is with a semicolon, {{{ Prelude> data Infix a b = a :@: b; infixl 4 :@: -- this is OK, but: Prelude> data Infix a b = a :@: b Prelude> infixl 4 :@: <interactive>:12:10: error: The fixity signature for `:@:' lacks an accompanying binding (The fixity signature must be given where `:@:' is declared) }}} This inconsistency is surprising and at times frustrating. Let's decide how we want semicolons to work and stick with it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11392> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9052: Support a "stable heap" which doesn't get garbage collected
by GHC 13 Nov '17

13 Nov '17

#9052: Support a "stable heap" which doesn't get garbage collected ----------------------------------------------+---------------------------- Reporter: ezyang | Owner: Type: feature request | simonmar Priority: normal | Status: new Component: Runtime System | Milestone: Keywords: | Version: 7.9 Architecture: Unknown/Multiple | Operating System: Difficulty: Moderate (less than a day) | Unknown/Multiple Blocked By: | Type of failure: Related Tickets: | None/Unknown | Test Case: | Blocking: ----------------------------------------------+---------------------------- Simon Marlow was explaining the concept on IRC. The problem we're trying to solve is you might have some very long-lived pointer data-structures, and you don't want to waste time traversing this structure on a major GC when you know that it is still going to be alive. Here's the basic idea: 1. We have a new generation on the heap called the 'stable heap' (along- side the nursery, gen0, gen1, etc). By default, no objects are automatically promoted from the old gen to the stable heap. 2. A user can request an object be moved to the stable heap, creating a stable pointer which points to the object. 3. During garbage collection, all blocks in the stable heap are always considered reachable. We don't include the stable pointers in the root set (so we don't trace the stable heap), however, write barriers are processed as usual, and we promote any objects pointed to by the stable heap to the stable heap. 4. Users manually request the stable heap to be garbage-collected, usually after deallocating stable pointers. In short, the stable heap is just another generation, but one which (1) is only collected by user request, and (2) never receives objects from automatic promotion. This project fits in very nicely with the existing GC infrastructure, so if you understand how everything is laid out this should be reasonably easy to implement. Could be a good ticket for someone who wants to get their hands dirty with the GC. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9052> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9420: Impredicative type instantiation without -XImpredicativeTypes
by GHC 12 Nov '17

12 Nov '17

#9420: Impredicative type instantiation without -XImpredicativeTypes -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Consider this module: {{{ {-# LANGUAGE RankNTypes #-} module Bug where rank2 :: ((forall a. a -> a) -> b) -> () rank2 _ = () foo :: () -> () foo x = x quux :: (forall a. a -> a) -> Int quux _ = 5 bar = foo . rank2 $ quux }}} The `(.)` in the definition of `bar` requires an impredicative instantiation -- that is, one of its type variables is instantiated to a forall-type. Yet, the module compiles without `-XImpredicativeTypes`. To confirm this behavior, the following is an excerpt from `-ddump-simpl`: {{{ Bug.bar = break<7>() (break<6>() GHC.Base.. @ () @ () @ ((forall a_a1Tj. a_a1Tj -> a_a1Tj) -> GHC.Types.Int) Bug.foo (Bug.rank2 @ GHC.Types.Int)) Bug.quux }}} Note the third type argument to `(.)`. Fixing this would be a breaking change that could affect users. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9420> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9642: LANGUAGE pragma synonyms
by GHC 11 Nov '17

11 Nov '17

#9642: LANGUAGE pragma synonyms -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Here are the first 20 lines of a typical Haskell file of mine: {{{ {-# LANGUAGE EmptyDataDecls #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE LiberalTypeSynonyms #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE StandaloneDeriving #-} {-# LANGUAGE AutoDeriveTypeable #-} {-# LANGUAGE DeriveDataTypeable #-} {-# LANGUAGE DeriveGeneric #-} {-# LANGUAGE DefaultSignatures #-} {-# LANGUAGE OverlappingInstances #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE ConstraintKinds #-} }}} Over a couple of modules in a small package, I find myself copy-pasting these 20 lines, as either I will use these extensions, or they won't really cause any harm to the code I'm writing. As a way to simplify this, and reduce code duplication, I propose introducing LANGUAGE pragma synonyms: {{{ {-# LANGUAGE PedrosHaskell = EmptyDataDecls, FlexibleContexts, FlexibleInstances , LiberalTypeSynonyms, ScopedTypeVariables , RankNTypes, StandaloneDeriving, AutoDeriveTypeable , DeriveDataTypeable, DeriveGeneric, DefaultSignatures , OverlappingInstances, UndecidableInstances , MultiParamTypeClasses, TypeOperators, TypeFamilies , GADTs, DataKinds, PolyKinds, ConstraintKinds #-} }}} After writing this, in that same module or any module that imports it, I could just write: {{{ {-# LANGUAGE PedrosHaskell #-} }}} And all the pragmas above would be enabled. Besides making my life easier, I suspect this will also help increase modularity of certain packages. For example, packages could define a package-specific language pragma that should be enabled in order to use that package. Then, if the package maintainer upgrades one datatype to become a GADT, the pragma would be updated to include `GADTs`, and user code (that could now be requiring that pragma) would automatically enable `GADTs` too. Furthermore, it can also make the language standardisation process simpler. After all, {{{ {-# LANGUAGE Haskell2010 = PatternGuards, NoNPlusKPatterns, RelaxedPolyRec , EmptyDataDecls, ForeignFunctionInterface #-} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9642> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #12623: Make Harbormaster less terrible in the face of submodule updates
by GHC 11 Nov '17

11 Nov '17

#12623: Make Harbormaster less terrible in the face of submodule updates -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamarii Type: task | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently submodule updates appear to break Harbormaster builds. This is bad. Fix it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12623> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13122: Investigate reporting build errors with harbormaster.sendmessage
by GHC 11 Nov '17

11 Nov '17

#13122: Investigate reporting build errors with harbormaster.sendmessage -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The phabricator API provides a method `harbormaster.sendmessage` which allows builds to report information back so that it is displayed on the interface. The goal is to avoid having to delve into the build logs in order to investigate failures. Information about the API method can be found in [https://phabricator.haskell.org/conduit/method/harbormaster.sendmessage/ conduit]. The API provides a rich set of options to report different information about a build. Some ideas: * Reporting the precise location of all terminal build errors * Reporting the outcome of all tests (this might be quite noisy but the only way to see is to try!) I don't know whether this is a good idea or how it works precisely but integrating harbourmaster with differential would be an efficiency gain. This is potentially related to #8809. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13122> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4