October 2016 - ghc-tickets

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

11 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 10 Nov '17

10 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 10 Nov '17

10 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] #12363: Type application for infix
by GHC 10 Nov '17

10 Nov '17

#12363: Type application for infix -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | 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: -------------------------------------+------------------------------------- `1 + @Int 10` is a parse error, I would like it to mean the same as {{{#!hs (+) @Int 1 10 }}} Thoughts? ---- Also {{{#!hs >>> pure `foldMap` @Maybe @[_] Just 'a' "a" >>> foldMap @Maybe @[_] pure (Just 'a') "a" }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12363> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 25

[GHC] #8238: Implement unloading of shared libraries
by GHC 09 Nov '17

09 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] #12791: Superclass methods could be more aggressively specialised.
by GHC 08 Nov '17

08 Nov '17

#12791: Superclass methods could be more aggressively specialised. -------------------------------------+------------------------------------- Reporter: mpickering | 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: -------------------------------------+------------------------------------- Say `R` is a superclass of `MR` but only uses one of the type variables. If this type variable is fixed then we know that we are going to use the specific dictionary. Thus, the optimiser *could* specialise all methods from the superclass at this point leading to better code. {{{#!hs {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FlexibleContexts #-} module Foo where class R t => MR t m where push :: t -> m -> Int class R t where pull :: t -> Int --type MR2 t m = (R t, MR t m) instance MR Int Int where push = max instance R Int where pull = negate myf :: (MR Int a) => a -> Int -> Int myf _ = pull }}} To give a concrete example, `R` is a super class of `MR` but only mentions the first type variable. Thus when we fix it in `myf`, we could optimise the definition to `myf _ = negate` by inlining the class method. Reid points out that if you have a definition like {{{ data X = X f :: R X => Int -> Int f = pull }}} then the instance for `R X` could be provided by another module. However it is common to structure large applications with super class constraints so it would be desirable to do better. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12791> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 35

[GHC] #11267: Can't parse type with kind ascription with GHCi's :kind command
by GHC 04 Nov '17

04 Nov '17

#11267: Can't parse type with kind ascription with GHCi's :kind command -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.3 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 was playing around with GHCi's `:kind` command and noticed that trying to ascribe a type with a kind doesn't parse: {{{ $ inplace/bin/ghc-stage2 --interactive GHCi, version 7.11.20151219: http://www.haskell.org/ghc/ :? for help λ> :set -XTypeInType λ> :kind 'True :: Bool <interactive>:1:7: error: parse error on input ‘::’ }}} This seems like something that should be able to parse, given that `:type True :: Bool` parses just fine. Is there a reason it couldn't? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11267> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12199: GHC is oblivious to injectivity when a type family is used in a GADT type
by GHC 04 Nov '17

04 Nov '17

#12199: GHC is oblivious to injectivity when a type family is used in a GADT type -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: TypeFamilies, | Operating System: Unknown/Multiple Injective | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- [https://www.reddit.com/r/haskell/comments/4oeidw/type_family_dependencies_a… A reddit post] points out a limitation of injective type families: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE TypeFamilyDependencies #-} type family Foo a = b | b -> a where Foo Int = Bool data Bar :: * -> * where Bar :: a -> Bar (Foo a) oink :: Bar Bool -> Int oink (Bar x) = x -- type error }}} Compiling this fails with: {{{ Could not deduce: a ~ Int from the context: Bool ~ Foo a }}} Which seems odd, given that `Bool ~ Foo a` should imply `a ~ Int` by injectivity. Even if you change the type signature of `oink` to `Bar (Foo Int) -> Int`, it fails with: {{{ Could not deduce: a ~ Int from the context: Foo Int ~ Foo a }}} which makes it even more apparent that it isn't aware of the fact that `Foo` is injective. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12199> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

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

02 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