August 2015 - ghc-tickets

[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] #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] #8238: Implement unloading of shared libraries
by GHC 10 Nov '17

10 Nov '17

#8238: Implement unloading of shared libraries ------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 8039 | ------------------------------------+------------------------------------- In #8039 we added support for unloading static objects from the runtime linker, with the GC detecting when there are no references left. We could add this functionality for shared libraries too, using `dl_iterate_phdr`. @heisenbug's comment from #8039 with the relevant pointers: [http://eli.thegreenplace.net/2011/08/25/load-time-relocation-of-shared- libraries Eli Bendersky's article] suggests to use the [http://linux.die.net/man/3/dl_iterate_phdr dl_iterate_phdr] function for finding information about loaded libraries. Seems to be linux only. There is a [http://stackoverflow.com/questions/10009043/dl-iterate-phdr- equivalent-on-mac workaround on OSX], though, on !StackOverflow. And here is how Böhm-Demers-Weiser's GC implement a [https://github.com/ivmai/bdwgc/blob/master/dyn_load.c#L451 callback function for dl_iterate_phdr]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8238> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10514: Generic for existential types
by GHC 09 Nov '17

09 Nov '17

#10514: Generic for existential types -------------------------------------+------------------------------------- Reporter: | Owner: ekmett andreas.abel | Status: new Type: feature | Milestone: request | Version: 7.10.1 Priority: normal | Operating System: Unknown/Multiple Component: Core | Type of failure: None/Unknown Libraries | Blocked By: Keywords: | Related Tickets: Architecture: | Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I have some use for Generic for an existential type which is constraint to be Generic. {{{!#hs {-# LANGUAGE DeriveGeneric #-} {-# LANGUAGE ExistentialQuantification #-} {-# LANGUAGE StandaloneDeriving #-} import GHC.Generics data U = forall a. (Generic a) => U a -- deriving (Generic) -- Can't make a derived instance of ‘Generic U’: -- Constructor ‘U’ has existentials or constraints in its type -- Possible fix: use a standalone deriving declaration instead -- deriving instance Generic U -- Can't make a derived instance of ‘Generic U’: -- U must be a vanilla data constructor -- In the stand-alone deriving instance for ‘Generic U’ data D1Ser data C1_0Ser instance Generic U where type Rep U = D D1Ser (C1 C1_0Ser (S1 NoSelector (Rep a))) -- Not in scope: type variable ‘a’ -- How to bring the existential type `a' into scope? }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10514> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #10577: Use empty cases where appropriate when deriving instances for empty types
by GHC 03 Nov '17

03 Nov '17

#10577: Use empty cases where appropriate when deriving instances for empty types -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- In some sense the correct instance for {{{ data X deriving instance Eq X }}} is not (what GHC currently produces) {{{ instance Eq X where (==) = error "Void ==" }}} but rather {{{ instance Eq X where a == b = case a of {} -- using the EmptyCase extension }}} See comments starting at ticket:7401#comment:28 for justification. The list of classes that GHC can currently derive is * Eq, Ord, Enum, Bounded, Show, Read (Haskell 2010 Report) * Functor, Foldable, Traversable, Typeable, Generic, Data, "any class" (`-XDerive*`) Deriving Enum and Bounded is not currently allowed for empty data types. The `showList` method of Show and the whole Read instance are easy and already implemented correctly. All the remaining methods of Haskell 2010 derivable type classes take at least one argument of the instance head type `a`. I propose that all these methods be defined as an empty case on the first such argument. Similarly in Functor, Foldable and Traversable, each method has a single argument of the form `t _` where `t :: * -> *` is the instance head type, and the method should be defined as an empty case on that argument. In all these cases so far, the derived methods for a non-empty type would, at the outermost level, be a (non-empty) case on that first argument, or the equivalent (series of pattern matches, one for each constructor), so the use of an empty case is justified for an empty type. Typeable does not care about the values or even the kind of the type at all, so it's not relevant here. Generic and especially Data are above my pay grade, but generally I expect that methods which are normally defined by case analysis on an argument of the instance head type should be defined by an empty case, and methods that (sometimes) produce a value of the instance head type should do whatever they normally do when unable to produce such a value (like `readsPrec` returning an empty list, or `read` calling `error` (if `read` were actually a method of `Read`)). `DeriveAnyClass` doesn't generate any new code, so like Typeable it's not relevant. None of this behavior is specified by the Haskell 2010 Report, which disallows deriving any class for a type with no constructors; but see #7401. So, we are entitled to do what we think is best here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10577> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #8171: Extending ExtendedDefaultRules
by GHC 02 Nov '17

02 Nov '17

#8171: Extending ExtendedDefaultRules ------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The current `ExtendedDefaultRules` is set up in a way that largely prevents it from being used for scenarios beyond what they get used for in GHCi today. It would be great if there was an extra class that could be included in the list of acceptable classes for Rule 3. {{{ class Defaulting a }}} The proposed change would be that Rule 3 under EDR can be be relaxed to: At least one of the classes Ci is numeric, or is `Show`, `Eq`, `Ord` or `Defaulting`. I went with `Defaulting` rather than `Default`, because `Default` is a common class in use across the ecosystem from the `data-default` package, and I wanted to avoid gratuitous fallout. This would permit projects like Shae Erisson's `ghclive` from last year that need to use defaulting to not have to shoe-horn unnecessary `Show` constraints onto functions. Even better would be for that class to be polykinded! That opens up possibilities for expert users to get defaulting to fire on arguments of other kinds, which is impossible under the current EDR. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8171> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #9249: Link to "latest" user's guide
by GHC 02 Nov '17

02 Nov '17

#9249: Link to "latest" user's guide ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Documentation | 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 search (say, on Google) for a GHC-related bit of documentation, I variously get referred to old manuals. There doesn't seem to a good way for us, the GHC devs, to avoid this. But, perhaps we can include some information in the header of the pages to allow visitors to link to the latest manual, or perhaps to several versions. This header should also include the version number of the GHC that the page is documenting; currently, this info is only in the URL. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9249> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9112: data families with representational matching
by GHC 18 Oct '17

18 Oct '17

#9112: data families with representational matching ------------------------------------+------------------------------------- Reporter: jwlato | 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: | ------------------------------------+------------------------------------- Since ghc-7.8, the following is no longer possible: {{{ -- simplified example taken from the vector package class MVectorClass (v :: * -> * -> *) a where basicLength :: v s a -> Int data family MVector s a data instance MVector s Int -- implementation not important newtype Age = Age Int deriving (MVectorClass MVector) -- rejected }}} Following from discussion in #8177, to enable this ghc would need to support data families with representational matching, such that `MVector s Int` and `MVector s Age` are representationally equal. This has broken some code that previously worked, however as there are some workarounds I'm not sure how important it is. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9112> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14