- ghc-tickets - Haskell.org

[GHC] #14587: Unidirectional pattern signatures do not need to be invariant w.r.t. higher-rank polymorphism
by GHC 15 Dec '17

15 Dec '17

#14587: Unidirectional pattern signatures do not need to be invariant w.r.t. higher-rank polymorphism -------------------------------------+------------------------------------- Reporter: goldfire | 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: -------------------------------------+------------------------------------- Best explained by example: {{{#!hs data T = MkT (forall a. a -> a) pattern PT :: (Int -> Int) -> T pattern PT x <- MkT x }}} This looks perfectly reasonable to me. And the hand-written matcher is also accepted. Note that a similar bidirectional pattern synonym should indeed be rejected. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14587> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #11203: Kind inference with SigTvs is wrong
by GHC 15 Dec '17

15 Dec '17

#11203: Kind inference with SigTvs is wrong -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider {{{#!hs data SameKind :: k -> k -> * data Q (a :: k1) (b :: k2) c = MkQ (SameKind a b) }}} This code should be rejected. Yet it is accepted. The problem is that, when kind-checking a datatype declaration without a CUSK, GHC uses `SigTv`s for user-written kind variables. `SigTv`s are allowed to unify with other `SigTv`s, leading to incorrect behavior here. The motivating scenario is this: {{{#!hs data T (a :: k1) x = MkT (S a ()) data S (b :: k2) y = MkS (T b ()) }}} This program should be accepted. Neither type has a CUSK and therefore is not generalized before kind-checking the group. GHC must then unify `k1` and `k2`. If they were skolems, this unification would fail and this pair of definitions would be rejected. This ticket is identical in spirit to #9201, but that example has a CUSK and thus works. The bug can happen only when there is no CUSK. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11203> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

Re: [GHC] #5642: Deriving Generic of a big type takes a long time and lots of space
by GHC 15 Dec '17

15 Dec '17

#5642: Deriving Generic of a big type takes a long time and lots of space -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.3 Resolution: | Keywords: deriving- | perf, Generics Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: T5642 Blocked By: | Blocking: Related Tickets: #13059 | Differential Rev(s): Phab:D2304 Wiki Page: | -------------------------------------+------------------------------------- Changes (by nh2): * cc: nh2 (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5642#comment:51> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14586: ARM and ARM64 NCG
by GHC 15 Dec '17

15 Dec '17

#14586: ARM and ARM64 NCG -------------------------------------+------------------------------------- Reporter: dobenour | Owner: (none) Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- This is a feature request for an ARM and ARM64 NCG. This will vastly speed up compile time for those targeting mobile devices. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14586> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14585: Consider doing a CPS→SSA conversion in the backend
by GHC 15 Dec '17

15 Dec '17

#14585: Consider doing a CPS→SSA conversion in the backend -------------------------------------+------------------------------------- Reporter: dobenour | Owner: (none) Type: task | 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: -------------------------------------+------------------------------------- GHC currently uses CPS when generating code. This is difficult to map to LLVM, and even in the NCG may result in suboptimal use of the CPU, since CPUs are optimized for C-like languages. It might be worthwhile to convert from CPS to SSA form in the backend and then optimize ''that''. This would require a bunch of changes to the RTS, and add an entire new IR, but could enable optimizations that would otherwise be impossible. To avoid a big compile-time regression, the SSA IR should be represented as a flat array, rather than a sea of linked nodes. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14585> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14583: Don’t use `String` when generating code
by GHC 15 Dec '17

15 Dec '17

#14583: Don’t use `String` when generating code -------------------------------------+------------------------------------- Reporter: dobenour | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (CodeGen) | 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: -------------------------------------+------------------------------------- GHC uses `String` when generating code, which is very slow. It would be much better to switch to `Data.ByteString.Builder`, or better yet output executables directly rather than going through an assembler. This applies to both the native and LLVM code generators. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14583> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14515: "Same" higher-rank kind synonyms behave differently
by GHC 15 Dec '17

15 Dec '17

#14515: "Same" higher-rank kind synonyms behave differently -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- As you know type-level `forall`s don't float, so we may want to write `HRefl`'s kind {{{#!hs -- Different from -- HREFL :: forall k1 k2. k1 -> k2 -> Type -- data HREFL :: forall k1. k1 -> (forall k2. k2 -> Type) where HREFL :: HREFL a a }}} Let us capture `forall k2. k2 -> ..` with a kind synonym {{{#!hs type HRank2 ty = forall k2. k2 -> ty data HREFL :: forall k. k -> HRank2 Type where HREFL :: HREFL a a }}} Works fine. Phew. Let's do the same for `forall k1. k1 -> ..` {{{#!hs type HRank1 ty = forall k1. k1 -> ty type HRank2 ty = forall k2. k2 -> ty data HREFL :: HRank1 (HRank2 Type) where HREFL :: HREFL a a }}} Works fine. Phew. “Didn't you just define the same kind synonym twice?” The funny thing is that this fails to compile when they coincide! {{{#!hs data HREFL :: HRank1 (HRank1 Type) -- FAILS data HREFL :: HRank1 (HRank2 Type) -- OK data HREFL :: HRank2 (HRank1 Type) -- OK data HREFL :: HRank2 (HRank2 Type) -- FAILS }}} {{{ $ ghci -ignore-dot-ghci /tmp/Weird.hs GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/Weird.hs, interpreted ) /tmp/Weird.hs:8:1: error: • These kind and type variables: (b :: k2) k2 (d :: k2) are out of dependency order. Perhaps try this ordering: k2 (b :: k2) (d :: k2) • In the data type declaration for ‘HREFL’ | 8 | data HREFL :: HRank2 (HRank2 Type) | ^^^^^^^^^^ Failed, 0 modules loaded. Prelude> }}} Same happens defining `HRank2` in terms of `HRank1` {{{#!hs type HRank1 ty = forall k1. k1 -> ty type HRank2 ty = HRank1 ty }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14515> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #4020: Please consider adding support for local type synonyms
by GHC 14 Dec '17

14 Dec '17

#4020: Please consider adding support for local type synonyms -------------------------------------+------------------------------------- Reporter: nr | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 6.12.2 checker) | Resolution: | Keywords: type synonym Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AntC): Replying to [comment:18 ezyang]: > Yeah, local type synonyms are probably the least controversial Thanks Edward, but I see no controversy. Only the usual questions about what are the use cases/benefits? what does it provide that can't be written now/only written clumsily? how does it work? what complications does the user need to understand? what complications does the compiler need to understand? > of "make global things possible locally" proposals. There are pretty clear semantics for how it works in all cases. Then it should be easy for someone to write up a proposal on github. I've seen plenty of "make global things possible locally" proposals. None of them have given a coherent explanation for how the local thing is to behave when something containing it or mentioning it or bound to it gets exported globally. (For example with class instances; that's why Wadler made them global despite his initial proposal making them let-bound.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4020#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4020: Please consider adding support for local type synonyms
by GHC 14 Dec '17

14 Dec '17

#4020: Please consider adding support for local type synonyms -------------------------------------+------------------------------------- Reporter: nr | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 6.12.2 checker) | Resolution: | Keywords: type synonym Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AntC): Replying to [comment:17 pggiarrusso]: > A local type synonym should arguably be expanded, and only be in scope in its where clause, or in general in the lexical scope of the declaration. Probably the synonym should be expanded when exiting the synonym’s scope, so that error messages for type errors in the block use the synonym and not its expansion. GHC constantly strives to provide error messages that pinpoint a problem as closely as possible. Consider {{{ x :: String x = "hello" y :: [Char] y = "world" xy = x + y -- error: no instance for (Num String) yx = y + x -- error: no instance for (Num [Char]) }}} So the error message uses the declared type/synonym where it can. (I imagine that's rather fragile.) It doesn't look for a synonym that would be equivalent to some type. Why not: declare the synonym at top level, as usual; omit it from the module's export list so its scope is only the module; if you want a let- bound var declared with the synonym you can, and error messages will use that. Yes, lambda-lift for lexically scoped type vars. I'm not seeing that's a big burden. But if it is, perhaps it'll spur someone to put in a properly explained proposal on github. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4020#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14135: PatternSynonyms regression in GHC HEAD (expectJust mkOneConFull)
by GHC 14 Dec '17

14 Dec '17

#14135: PatternSynonyms regression in GHC HEAD (expectJust mkOneConFull) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This code works in GHC 8.2: {{{#!hs {-# LANGUAGE PatternSynonyms #-} module Bug where data Foo a = Foo1 a | Foo2 a pattern MyFoo2 :: Int -> Foo Int pattern MyFoo2 i = Foo2 i {-# COMPLETE Foo1, MyFoo2 #-} f :: Foo a -> a f (Foo1 x) = x }}} But it throws a compile-time exception on GHC HEAD: {{{ $ ghc3/inplace/bin/ghc-stage2 Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.3.20170815 for x86_64-unknown-linux): expectJust mkOneConFull CallStack (from HasCallStack): error, called at compiler/utils/Maybes.hs:53:27 in ghc:Maybes expectJust, called at compiler/deSugar/Check.hs:1128:37 in ghc:Check }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14135> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22