- ghc-tickets - Haskell.org

[GHC] #15988: Remove Text.Printf and System.Console.GetOpt from base
by GHC 03 Dec '18

03 Dec '18

#15988: Remove Text.Printf and System.Console.GetOpt from base -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 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: -------------------------------------+------------------------------------- This was touched on in brief in a recent mailing list thread found at https://mail.haskell.org/pipermail/libraries/2018-October/029012.html. I propose removing `Text.Printf` and `System.Console.GetOpt` from `base` and moving them into their own packages named `printf` and `getopt` that would be managed by the haskell github organization. These two libraries, when built against newer versions of base, would provide the modules. When built against old versions of base, they would simply reexport the modules. There would be breakage from doing this, but libraries and applications that use these APIs would only need to add a single line to `build-depends` to continue being compatible with all versions of `base`. The benefits of doing this are small. As a matter of principle, it seems unfair that these two APIs are blessed by being a part of base when the would likely struggle to compete if they were in ordinary libraries. In particular, `printf` is less idiomatic and performs worse that the functions from `Numeric` (like `showFFloat`), but its prominent position in `base` encourages users to overlook the more type-safe options available for formatting numbers. More practically, the size of base does occassionally cause problems. In https://github.com/haskell/primitive/issues/218#issuecomment-443534850, Carter writes > base getting bigger actually hurts folk, eg, base recently got big enough that dwarf data gnerated by ghc at -g1 is now sooo much that you can't do a dwarf annotated build of base on mac OS X! anymore Moving these APIs out of `base` makes a small step toward addressing this problem. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15988> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10930: missing empty-Enumeration warning for `Natural`
by GHC 03 Dec '18

03 Dec '18

#10930: missing empty-Enumeration warning for `Natural` -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: low | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #7881, #10929 Differential Rev(s): | -------------------------------------+------------------------------------- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10930> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #15954: LiberalTypeSynonyms unsaturation check doesn't kick in
by GHC 03 Dec '18

03 Dec '18

#15954: LiberalTypeSynonyms unsaturation check doesn't kick in -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC accepts this program: {{{#!hs {-# LANGUAGE ImpredicativeTypes #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} module Bug where import GHC.Exts (Any) type KindOf (a :: k) = k type A a = (Any :: a) type KA = KindOf A }}} But it really oughtn't to. After all, we have an unsaturated use of `A` in `KindOf A`, and we don't have `LiberalTypeSynonyms` enabled! What's even stranger is that there seems to be something about this exact setup that sneaks by `LiberalTypeSynonyms`' validity checks. If I add another argument to `A`: {{{#!hs type A x a = (Any :: a) }}} Then it //does// error: {{{ $ /opt/ghc/8.6.2/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:10:1: error: • Illegal polymorphic type: forall a -> a Perhaps you intended to use LiberalTypeSynonyms • In the type synonym declaration for ‘KA’ | 10 | type KA = KindOf A | ^^^^^^^^^^^^^^^^^^ }}} Similarly, if I use something besides `KindOf`: {{{#!hs {-# LANGUAGE ImpredicativeTypes #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} module Bug where import GHC.Exts (Any) type A a = (Any :: a) type B a = Int type C = B A }}} Then I also get the same `Illegal polymorphic type: forall a -> a` error. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15954> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #15985: `pprint EqualityT` infinitely loops
by GHC 03 Dec '18

03 Dec '18

#15985: `pprint EqualityT` infinitely loops -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Template | Version: 8.6.2 Haskell | 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: -------------------------------------+------------------------------------- I was very surprised to discover that this program loops infinitely: {{{#!hs module Main where import Language.Haskell.TH main :: IO () main = print $ pprint EqualityT }}} Let's not do that. Patch incoming. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15985> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9505: Bounded instance for Word (and possibly others) uses unboxed literals
by GHC 03 Dec '18

03 Dec '18

#9505: Bounded instance for Word (and possibly others) uses unboxed literals -------------------------------------+------------------------------------- Reporter: schyler | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- There's a comment above saying GHC won't optimise. I think since 7.8 they are unboxed by default, so that comment and the explicit constructors can be removed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9505> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #14298: Let Template Haskell dynamically add a library against which to link
by GHC 03 Dec '18

03 Dec '18

#14298: Let Template Haskell dynamically add a library against which to link -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Template | Version: 8.2.1 Haskell | 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: -------------------------------------+------------------------------------- As of today, Template Haskell supports emitting foreign files (for C compiler languages) via `addForeignFile`. In doing so, GHC takes on the work of compiling these, linking against them, and then cleaning up any other files. This makes packages like `inline-c` ([https://hackage.haskell.org/package/inline-c] possible, where you can write C snippets in quasiquotes and these can interact with your Haskell code. The user doesn't need to pass extra options to GHC (except to enable the right language extensions), and they don't have to see any of the intermediate generated artifacts. Unfortunately, that breaks down for non C compiler languages. It would be nice for TH to also support directly adding a static library, since then one could * use TH's `runIO` to generate static libraries by calling out to whatever other compilers * add the contents of those libraries via TH * delete the temporary files created in the process (again using `runIO`) * have GHC statically link against the content (from the second bullet point) I'm not sure what the API for this could be, but maybe adding a `StaticLibrary` constructor to the `ForeignSrcLang` data type (so one could use `addForeignFile :: ForeignSrcLang -> String -> Q ()`)? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14298> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #15987: GHC sometimes not computing open type family application in kind inference
by GHC 03 Dec '18

03 Dec '18

#15987: GHC sometimes not computing open type family application in kind inference -------------------------------------+------------------------------------- Reporter: sheaf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 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: -------------------------------------+------------------------------------- In writing code for type-level lenses, I've run into an issue with kind inference. I've boiled it down to the following oddity: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeFamilies #-} module Bug where import Data.Kind(Type) type family FooKind (a :: Type) :: k class Foo (a :: Type) where type FooType a :: FooKind a -- OK type instance FooKind Bool = Type instance Foo Bool where type FooType Bool = Int -- not OK data A type instance FooKind A = Type instance Foo A where type FooType A = Int }}} This produces the following error: • Expected kind ‘FooKind A’, but ‘Int’ has kind ‘Type’ • In the type ‘Int’ In the type instance declaration for ‘FooType’ In the instance declaration for ‘Foo A’ I thought it might be related to the type family FooKind being polymorphic in its return kind, but changing the return kind to 'Type' does not affect this. \\ Changing "FooKind" to be a closed type family fixes this problem. \\ \\ \\ For the context in which this came up, I was writing type-level optics of which one can take the product (with disjointness guaranteed at the type level with type families). Then I needed a type family that chooses which product to use. For instance I have kind annotations: {{{#!hs ( (Index 0 :: Optic (V Int 3) Int) :*: (Index 2 :: Optic (V Int 3) Int) ) :: Optic (V Int 3) (V Int 2) ) type Fields = '[ '("a", Int), '("b", Bool), '("c", Float) ] ( (Name "a" :: Optic (Struct Fields) Int :*: (Name "c" :: Optic (Struct Fields) Float ) :: Optic Fields '[ '("a", Int), '("c", Float) ] }}} The type family :*: thus needs to figure out which product structure to use... in the first case I need to use V Int :: Nat -> Type, and in the second Struct :: [(Symbol,Type)] -> Type. \\ I wanted to use open type families for extensibility of which cartesian structure to use. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15987> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12643: class declaration works in ghci, but not in a file
by GHC 03 Dec '18

03 Dec '18

#12643: class declaration works in ghci, but not in a file -------------------------------------+------------------------------------- Reporter: dmwit | 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: -------------------------------------+------------------------------------- The following ghci session prints no errors: {{{ > :set -XStandaloneDeriving -XDeriveGeneric > import GHC.Generics > import Control.Monad.Except > deriving instance Generic (ExceptT e m a) > class F a where f :: Rep (Except String a) x }}} However, when I transfer this to a file: {{{ {-# LANGUAGE StandaloneDeriving #-} {-# LANGUAGE DeriveGeneric #-} import GHC.Generics import Control.Monad.Except deriving instance Generic (ExceptT e m a) class F a where f :: Rep (Except String a) x }}} I get a mysterious error: {{{ test.hs:6:17: error: • Couldn't match type ‘Rep (Except String a0)’ with ‘Rep (Except String a)’ Expected type: Rep (Except String a) x Actual type: Rep (Except String a0) x NB: ‘Rep’ is a type function, and may not be injective The type variable ‘a0’ is ambiguous • In the ambiguity check for ‘f’ To defer the ambiguity check to use sites, enable AllowAmbiguousTypes When checking the class method: f :: forall a. F a => forall x. Rep (Except String a) x In the class declaration for ‘F’ }}} If I turn on -fdefer-type-errors, I can verify that the type family indeed reduces far enough for a and x to be arguments to injective types, so I believe GHC should not consider this an error: {{{ > :set -XRankNTypes > :kind! forall a x. Rep (Except String a) x forall a x. Rep (Except String a) x :: * = D1 ('MetaData "ExceptT" "Control.Monad.Trans.Except" "transformers-0.5.2.0" 'True) (C1 ('MetaCons "ExceptT" 'PrefixI 'False) (S1 ('MetaSel 'Nothing 'NoSourceUnpackedness 'NoSourceStrictness 'DecidedLazy) (Rec0 (Data.Functor.Identity.Identity (Either [Char] a))))) x }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12643> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15561: TypeInType: Type error conditioned on ordering of GADT and type family definitions
by GHC 03 Dec '18

03 Dec '18

#15561: TypeInType: Type error conditioned on ordering of GADT and type family definitions -------------------------------------+------------------------------------- Reporter: Bj0rn | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: TypeInType, | Operating System: Unknown/Multiple TypeFamilies, GADTs | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider this code which successfully compiles: {{{#!hs {-# LANGUAGE TypeInType, TypeFamilies, GADTs #-} module Bug where class HasIndex a where type Index a emptyIndex :: IndexWrapper a instance HasIndex [a] where type Index [a] = Int emptyIndex = Wrap 0 data IndexWrapper a where Wrap :: Index a -> IndexWrapper a type family UnwrapAnyWrapperLikeThing (a :: t) :: k type instance UnwrapAnyWrapperLikeThing ('Wrap a :: IndexWrapper [b]) = a }}} The mere act of moving the definition of `IndexWrapper` anywhere below the definition of `UnwrapAnyWrapperLikeThing` makes the type family instance at the bottom of the example fail compilation, with this error: {{{ Bug.hs:17:15: error: • Illegal type synonym family application in instance: Index [b] • In the type instance declaration for ‘UnwrapAnyWrapperLikeThing’ | 17 | type instance UnwrapAnyWrapperLikeThing ('Wrap a :: IndexWrapper [b]) = a | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} This is the smallest example that I could come up with; my real scenario of course has more things going on, but I can share if it would help. The problem for me (other than that I'm pretty sure reordering definitions in Haskell should never affect anything) is that I would like just the definition of the type family (`UnwrapAnyWrapperLikeThing` in this example) in module `A` and all of the other definitions in module `B` that imports `A`. Ideally, I would have liked to add a `HasIndex a` constraint to the `Wrap` constructor, but that disqualifies use of `'Wrap` on the type level. This does make me feel like I'm on shaky ground to begin with. I have reproduced this bug on 8.2.2, 8.4.3 and 8.6.0.20180810 (NixOS). I should note that 8.0.2 rejects even the code that I pasted here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15561> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #14668: Ordering of declarations can cause typechecking to fail
by GHC 03 Dec '18

03 Dec '18

#14668: Ordering of declarations can cause typechecking to fail -------------------------------------+------------------------------------- Reporter: heptahedron | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Type checker) | 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 following will successfully typecheck: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeFamilies #-} data CInst data G (b :: ()) = G class C a where type family F a class (C a) => C' a where type family F' a (b :: F a) -- data CInst instance C CInst where type F CInst = () instance C' CInst where type F' CInst (b :: F CInst) = G b }}} But if the `data CInst` declaration is moved to where it is currently commented out, typechecking fails with this error: {{{ Test.hs:23:18: error: • Expected kind ‘F CInst’, but ‘b’ has kind ‘()’ • In the second argument of ‘F'’, namely ‘(b :: F CInst)’ In the type instance declaration for ‘F'’ In the instance declaration for ‘C' CInst’ | 23 | type F' CInst (b :: F CInst) = G b | }}} However, the data declaration //can// be in the lower position if the kind annotation for its argument is instead written as `data G (b :: F CInst) = G`. This behavior is also exhibited when G is a type family (I believe the sort of type family does not matter, but I know for sure closed and open type families). I was using GHC 8.2.2 when I discovered this, but user `erisco` on `#haskell` confirmed for 8.2.1 as well. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14668> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8