December 2018 - ghc-tickets

[GHC] #15983: Built-in support for half-floats
by GHC 04 Dec '18

04 Dec '18

#15983: Built-in support for half-floats -------------------------------------+------------------------------------- Reporter: lerkok | Owner: (none) Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- Half-floats (16-bit floating point values with 1-bit sign, 5-bits of exponent, and 10 bits of mantissa) are becoming more and more common in this new era of data-centric programming: Almost all GPUs have native support, and most CPU's are starting to support them natively in their instruction set. It would be great if GHC can lead the way and have half-floats as a natively supported data-type as well, just like Float and Double. I'm aware of Edward's http://hackage.haskell.org/package/half package; so that could be a starting point; though we'd eventually want GHC to generate native code. Note that LLVM does support half-floats, so a viable path can be using LLVM when available and software-FFI/implementation otherwise. Eventually the native code generator can add support as well. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15983> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #7503: Bug with PolyKinds, type synonyms & GADTs
by GHC 04 Dec '18

04 Dec '18

#7503: Bug with PolyKinds, type synonyms & GADTs -------------------------------------+------------------------------------- Reporter: Ashley Yakeley | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.6.1 checker) | Keywords: GADTs, Resolution: | TypeInType Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T7503a Blocked By: | Blocking: Related Tickets: #14451 | Differential Rev(s): Wiki Page: | https://ghc.haskell.org/trac/ghc/wiki/GhcKinds/KindInference| -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => typecheck/should_compile/T7503a Comment: I've added a test case for the first program in comment:10 as `T7503a`. A test case for the other program—which I'd assume would be called `T7503b`—must wait for another day. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7503#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14451: Type synonym of type family causes error, error jumps to (fairly) unrelated source location
by GHC 04 Dec '18

04 Dec '18

#14451: Type synonym of type family causes error, error jumps to (fairly) unrelated source location -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- {{{#!hs {-# Language KindSignatures, TypeOperators, PolyKinds, TypeOperators, ConstraintKinds, TypeFamilies, DataKinds, TypeInType, GADTs, AllowAmbiguousTypes, InstanceSigs, RankNTypes, UndecidableInstances #-} import Data.Kind data TyFun :: Type -> Type -> Type type a ~> b = TyFun a b -> Type type Cat ob = ob -> ob -> Type type family Apply (f :: a ~> b) (x :: a) :: b where Apply (CompSym2 f g) a = Comp f g a data CompSym2 :: (b ~> c) -> (a ~> b) -> (a ~> c) type a·b = Apply a b class Varpi (f :: i ~> j) where type Dom (f :: i ~> j) :: Cat i type Cod (f :: i ~> j) :: Cat j varpa :: Dom f a a' -> Cod f (f·a) (f·a') type family Comp (f::k1 ~> k) (g::k2 ~> k1) (a::k2) :: k where Comp f g a = f · (Apply g a) }}} This compiles, but if I replace the final line by {{{#!hs Comp f g a = f · (g · a) }}} oddly enough I get an error message about the method `varpa`! Seemingly unrelated apart from using `(·)`: {{{ $ ghci2 hs/093-bug.hs GHCi, version 8.3.20170920: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( hs/093-bug.hs, interpreted ) hs/093-bug.hs:23:33: error: • Expected kind ‘i ~> i’, but ‘f’ has kind ‘i ~> j’ • In the first argument of ‘(·)’, namely ‘f’ In the second argument of ‘Cod’, namely ‘(f · a)’ In the type signature: varpa :: Dom f a a' -> Cod f (f · a) (f · a') | 23 | varpa :: Dom f a a' -> Cod f (f·a) (f·a') | ^ Failed, 0 modules loaded. Prelude> }}} NOW — let's randomly remove both lines that mention `CompSym2` and it mysteriously works, again! `Apply` and `(·)` seem to be equal up to variable names, I can't spot why {{{ >> :set -fprint-explicit-foralls >> :set -fprint-explicit-kinds >> :set -fprint-explicit-coercions >> >> :kind Apply Apply :: forall {a} {b}. (a ~> b) -> a -> b >> :kind (·) (·) :: forall {a} {k}. (a ~> k) -> a -> k }}} but it works if I define `(·)` as a type family rather than a synonym: {{{#!hs type family (f::a ~> b) · (x::a) :: b where f · x = Apply f x }}} so it's some difference between synonyms and TFs, but is it intentional? It's certainly odd how the error messages jumped the `varpa` method when we actually modified `Comp`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14451> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

Re: [GHC] #7503: Bug with PolyKinds, type synonyms & GADTs
by GHC 04 Dec '18

04 Dec '18

#7503: Bug with PolyKinds, type synonyms & GADTs -------------------------------------+------------------------------------- Reporter: Ashley Yakeley | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.6.1 checker) | Keywords: GADTs, Resolution: | TypeInType Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: #14451 | Differential Rev(s): Wiki Page: | https://ghc.haskell.org/trac/ghc/wiki/GhcKinds/KindInference| -------------------------------------+------------------------------------- Comment (by Ryan Scott <ryan.gl.scott@…>): In [changeset:"aef5d82543bb642a65f63e1f05f245b9cddafd8c/ghc" aef5d825/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="aef5d82543bb642a65f63e1f05f245b9cddafd8c" Add test cases for #7503, #14451 At some point between 8.4 and 8.6, two things were fixed: * The entirety of #14451. * One of the test cases in #7503. I've added this as T7503a. The other test case from that ticket still does /not/ work, so we'll have to add T7503b some other day. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7503#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15791: typeKind confuses Type and Constraint
by GHC 03 Dec '18

03 Dec '18

#15791: typeKind confuses Type and Constraint -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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 `typeKind` function takes a type and reports its kind. It gets this wrong, sometimes: if you ask for `typeKind` of the quantified constraint `Eq a => C a` (where `C` is a class), you get `Type`. This is wrong, though I don't have a concrete case where GHC misfires. We ''could'' fix `typeKind` to get this right, but doing so would require making the `FunTy` case recursive (right now, it always returns `Type`). This is wasteful, because most clients of `typeKind` do not care about the distinction between `Type` and `Constraint`. Instead, I propose making a new `tcTypeKind` which behaves correctly in this case. We could also muse about making `tcTypeKind` monadic so that it can look through unification variables. This might also simplify the story around `Note [The tcType invariant]`. Regardless of the "make monadic" idea, I claim that, when this is done, we should have `isPredTy` be functionally equivalent to `(== Constraint) . tcTypeKind`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15791> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #13256: Warn on out-of-range literals in pattern matches too
by GHC 03 Dec '18

03 Dec '18

#13256: Warn on out-of-range literals in pattern matches too -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- We have these nice warnings for numeric literal expressions that are out of range of their type: {{{ Prelude> 100000000000000000000000000000000 :: Int <interactive>:1:1: warning: [-Woverflowed-literals] Literal 100000000000000000000000000000000 is out of the Int range -9223372036854775808..9223372036854775807 }}} but nothing for numeric patterns: {{{ Prelude> (\x -> case (x :: Int) of 100000000000000000000000000000000 -> 0) 8 :: Int <interactive>:3:8: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In a case alternative: Patterns not matched: p where p is not one of {100000000000000000000000000000000} *** Exception: <interactive>:3:8-64: Non-exhaustive patterns in case }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13256> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[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