- ghc-tickets - Haskell.org

[GHC] #9151: Recursive default associated types don't kind-generalize properly
by GHC 21 Nov '14

21 Nov '14

#9151: Recursive default associated types don't kind-generalize properly ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | 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 {{{ {-# LANGUAGE PolyKinds, DataKinds, TypeFamilies, UndecidableInstances #-} module Bug where import Data.Proxy class PEnum (kproxy :: KProxy a) where type ToEnum (x :: a) :: Bool type ToEnum x = TEHelper type TEHelper = ToEnum Int }}} I get {{{ /Users/rae/temp/Bug.hs:11:24: The first argument of ‘ToEnum’ should have kind ‘a’, but ‘Int’ has kind ‘*’ In the type ‘ToEnum Int’ In the type declaration for ‘TEHelper’ }}} I believe my original code should kind-check, as `ToEnum` should be applicable to any kind. My guess is that this sort of recursion isn't properly accounted for in the kind-checking algorithm in !TcTyClsDecls, and that we kind-check `TEHelper` before `ToEnum` is kind-generalized. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9151> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #9220: type roles for unboxed arrays
by GHC 21 Nov '14

21 Nov '14

#9220: type roles for unboxed arrays -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 7.8.1 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- {{{ rwbarton@morphism:~$ ghci GHCi, version 7.8.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> :i Data.Array.Unboxed.UArray type role Data.Array.Base.UArray representational phantom data Data.Array.Base.UArray i e = Data.Array.Base.UArray !i !i {-# UNPACK #-} !Int GHC.Prim.ByteArray# -- Defined in ‘Data.Array.Base’ -- [instances trimmed] Prelude> :i Data.Array.IO.IOUArray type role Data.Array.IO.Internals.IOUArray representational phantom newtype Data.Array.IO.Internals.IOUArray i e = Data.Array.IO.Internals.IOUArray (Data.Array.Base.STUArray GHC.Prim.RealWorld i e) -- Defined in ‘Data.Array.IO.Internals’ Prelude> :i Data.Array.ST.STUArray type role Data.Array.Base.STUArray nominal representational phantom data Data.Array.Base.STUArray s i e = Data.Array.Base.STUArray !i !i {-# UNPACK #-} !Int (GHC.Prim.MutableByteArray# s) -- Defined in ‘Data.Array.Base’ Prelude> :i Data.Array.Storable.StorableArray type role Data.Array.Storable.Internals.StorableArray representational phantom data Data.Array.Storable.Internals.StorableArray i e = Data.Array.Storable.Internals.StorableArray !i !i Int !(GHC.ForeignPtr.ForeignPtr e) -- Defined in ‘Data.Array.Storable.Internals’ }}} These phantom roles for the element types let me create an unboxed array of one type (like Word8), cast it with `coerce` to another type (like Word64) and read outside the bounds of the array. I think they should all be nominal, since a newtype of an existing type could have a totally unrelated MArray or Storable instance. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9220> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 28

[GHC] #9209: Template haskell panic
by GHC 21 Nov '14

21 Nov '14

#9209: Template haskell panic ------------------------------------+------------------------------------- Reporter: tulcod | Owner: Type: bug | 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: | ------------------------------------+------------------------------------- I was trying to get some template haskell thing to work and was messing around and ran into this bug. Prelude> let $([d||]) ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-unknown-linux): cvBindsAndSigs $[splice{v}]([d| |]) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Prelude> The following file: {-# LANGUAGE TemplateHaskell #-} let $([d||]) main = do return () gives the following error message: test.hs:3:1: parse error (possibly incorrect indentation or mismatched brackets) but doesn't crash. So it seems to be ghci-specific...? the other oxford brackets work fine (or don't suffer from exactly the same bug, anyway) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9209> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #9788: `coerce` has an impossible type
by GHC 21 Nov '14

21 Nov '14

#9788: `coerce` has an impossible type -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- {{{ GHCi, version 7.8.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> :set -fprint-explicit-foralls Prelude> :set -fprint-explicit-kinds Prelude> import Data.Coerce Prelude Data.Coerce> :t coerce coerce :: forall (k :: BOX) (a :: k) (b :: k). Coercible k a b => a -> b }}} Are those types `a` and `b` really of kind `k`? They certainly shouldn't be. This is worse in HEAD: GHC panics. (Actually, I think panicking is an improvement.) Easy to fix, happily. Will do so in the course of other work. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9788> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9064: Support default class method signatures in Template Haskell
by GHC 21 Nov '14

21 Nov '14

#9064: Support default class method signatures in Template Haskell ------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | 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: | ------------------------------------+------------------------------------- If I say {{{ blah = [d| class C a where foo :: a -> String default foo :: Show a => a -> String foo = show |] }}} I get {{{ Illegal default signature for ‘[foo]’ Default signatures are not supported by Template Haskell }}} I would like this feature. I will implement this in due course. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9064> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9200: Milner-Mycroft failure at the kind level
by GHC 21 Nov '14

21 Nov '14

#9200: Milner-Mycroft failure at the kind level -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: Unknown/Multiple | valid program Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- This is a reduction of a problem that occurs in real code. {{{ {-# LANGUAGE PolyKinds #-} class D a => C (f :: k) a class C () a => D a }}} Typechecking complains: {{{ The first argument of ‘C’ should have kind ‘k’, but ‘()’ has kind ‘*’ In the class declaration for ‘D’ }}} This program should be accepted, but we're not generalizing enough. A slightly less reduced version of the problem arises in practice in: {{{ {-# LANGUAGE RankNTypes #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE PolyKinds #-} import Control.Category class (Category c, Category d, Category e) => Profunctor (p :: x -> y -> z) (c :: x -> x -> *) (d :: y -> y -> *) (e :: z -> z -> *) | p -> c d e -- lens-style isomorphism families in an arbitrary category type Iso (c :: i -> i -> *) (s :: i) (a :: i) = forall (p :: i -> i -> *). Profunctor p c c (->) => p a a -> p s s class Category e => Cartesian (e :: z -> z -> *) where type P e :: z -> z -> z associate :: Iso e (P e (P e a b) c) (P e a (P e b c)) }}} This typechecks, but if I replace the line {{{ class (Category c, Category d, Category e) => Profunctor }}} with {{{ class (Category c, Category d, Cartesian e) => Profunctor }}} to say that you can only enrich a category over a monoidal category (using `Cartesian` in the approximation here), then it fails because a more baroque version of the same kind of cycle as the minimal example above as Profunctor references Cartesian which references an Iso which mentions a Profunctor. I'm supplying explicit kind variables in the signature of the class, so we should be able to use those like we do with function signatures a universe down. =/ -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9200> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 46

[GHC] #8174: GHC should not load packages for TH if they are not used
by GHC 21 Nov '14

21 Nov '14

#8174: GHC should not load packages for TH if they are not used -------------------------+------------------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: | Milestone: 7.8.1 normal | Version: 7.6.3 Component: | Operating System: Unknown/Multiple Compiler | Type of failure: Compile-time performance bug Keywords: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- https://github.com/nh2/ghc-bug-th-loading When you call {{{ ghc --make -package mypackage }}} on a module that uses TH, you will see {{{ Loading package mypackage-1.2.3.4 ... linking ... done. }}} even if no code uses it. This slows down builds, especially cabal ones. GHCI does this better and only loads what is needed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8174> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #2437: More accurate package dependencies
by GHC 21 Nov '14

21 Nov '14

#2437: More accurate package dependencies -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: lowest | Milestone: 7.10.1 Component: Package | Version: 6.8.3 system | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: | Blocked By: None/Unknown | Related Tickets: #3560, #8174 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * related: => #3560, #8174 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2437#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9789: Make GHC accept .format+lhs as extension for literate haskell files
by GHC 20 Nov '14

20 Nov '14

#9789: Make GHC accept .format+lhs as extension for literate haskell files -------------------------------------+------------------------------------- Reporter: merijn | Owner: merijn 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: -------------------------------------+------------------------------------- I proposed this solution on the mailing list as a solution to allowing other tools to determine what the type of the non-haskell content in a literate haskell file is. For example, whether a document is markdown + literate haskell or reStructuredText + literate haskel. There were no real objections on the mailing list and this approach has been tested and works on Windows. Last discussion: https://www.haskell.org/pipermail/glasgow-haskell- users/2014-August/025228.html Initial discussion: https://www.haskell.org/pipermail/glasgow-haskell- users/2014-March/024745.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9789> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9703: Add missing calling conventions to Template Haskell
by GHC 20 Nov '14

20 Nov '14

#9703: Add missing calling conventions to Template Haskell -------------------------------------+------------------------------------- Reporter: luite | Owner: ekmett Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Template Haskell only supports the `CCall` and `StdCall` calling conventions, while GHC supports more: http://git.haskell.org/packages/template- haskell.git/blob/9bcc122819a6f4a2ae7ad569717324b8368e801c:/Language/Haskell/TH/Syntax.hs#l1311 http://git.haskell.org/ghc.git/blob/7369d2595a8cceebe457a44c8400828f4df87ea… `CApiConv`, `PrimCallConv` and `JavaScriptCallConv` are missing, and I think they should just be added unless this is expected to lead to problems. I'd personally like to have `JavaScriptCallConv` so I can remove the horrible hacks to make ghcjs-ffiqq (https://github.com/ghcjs/ghcjs-ffiqq) work. I imagine that `PrimCallConv` would be useful for a package using a similar approach for high performance inline assembly or LLVM with quasiquotes. A small change in GHC required to convert the new constructors, and possibly to check if the required extension is enabled. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9703> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8