September 2016 - ghc-tickets

[GHC] #12536: Clarify commentary surrounding unboxed tuples and kind invariant
by GHC 28 Oct '16

28 Oct '16

#12536: Clarify commentary surrounding unboxed tuples and kind invariant -------------------------------------+------------------------------------- Reporter: bgamari | Owner: simonpj 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: -------------------------------------+------------------------------------- ticket:12115#comment:8 notes that there are a few inconsistencies in the comments describing these areas. Simon, could you have a look? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12536> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12617: Make the interface of traceTc and traceRn the same
by GHC 26 Oct '16

26 Oct '16

#12617: Make the interface of traceTc and traceRn the same -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: new Priority: lowest | 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: -------------------------------------+------------------------------------- It always seemed strange to me that the interfaces for `traceTc` and `traceRn` were different. {{{#!hs traceTc :: String -> SDoc -> TcM () traceRn :: SDoc -> RnM () }}} I personally prefer using the `traceTc` interface and have to look up each time which function uses which interface. It seems beneficial but annoying to make `traceRn` have the same interface to improve usability slightly. Are there any objections if someone was to do this? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12617> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12522: GHC 8.0.1 hangs, looping forever in type-checker
by GHC 26 Oct '16

26 Oct '16

#12522: GHC 8.0.1 hangs, looping forever in type-checker -------------------------------------+------------------------------------- Reporter: clinton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm not sure if this is a bug or hanging the compiler is expected here. This was the minimal example that causes GHC to hang: {{{#!hs {-# LANGUAGE TypeFamilyDependencies #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE AllowAmbiguousTypes #-} main = return $ f (Just 'c') data D1 x data D2 type family TF x = t | t -> x type instance TF (D1 x, a) = Maybe (TF (x, a)) type instance TF (D2, ()) = Char class C p where f :: TF (x, a) -> () }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12522> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #9858: Typeable instance for datatype and its promoted constructor is the same
by GHC 26 Oct '16

26 Oct '16

#9858: Typeable instance for datatype and its promoted constructor is the same -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | 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: -------------------------------------+------------------------------------- {{{ {-# LANGUAGE DataKinds #-} {-# LANGUAGE AutoDeriveTypeable #-} import Data.Typeable data A = A main = print $ typeRep (Proxy :: Proxy A) == typeRep (Proxy :: Proxy 'A) }}} This returns `True`, but it should return `False`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9858> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 119

[GHC] #12507: Can't deduce implicit parameter
by GHC 24 Oct '16

24 Oct '16

#12507: Can't deduce implicit parameter -------------------------------------+------------------------------------- Reporter: Iceland_jack | 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: -------------------------------------+------------------------------------- I tried running a [https://gist.github.com/llelf/6c01ded225877914f38a gist] {{{#!hs {-# LANGUAGE GADTs, ConstraintKinds, Rank2Types, ImplicitParams #-} data Rec fields where Rec :: fields => Rec fields infixr 1 ? (?) :: Rec fields -> (fields => r) -> r Rec ? e = e record :: Rec (?a :: Int, ?b :: String) record = Rec where ?a=42 ?b="hey" access :: Int access = record ? ?a }}} and got {{{ $ ghci -ignore-dot-ghci tCHB.hs GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( tCHB.hs, interpreted ) tCHB.hs:15:19: error: • Could not deduce: ?a::Int arising from a use of implicit parameter ‘?a’ from the context: (?a::Int, ?b::String) bound by a type expected by the context: (?a::Int, ?b::String) => Int at tCHB.hs:15:10-20 • In the second argument of ‘(?)’, namely ‘?a’ In the expression: record ? ?a In an equation for ‘access’: access = record ? ?a Failed, modules loaded: none. Prelude> }}} I would certainly expect the context `(?a::Int, ?b::String)` to imply `?a::Int`? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12507> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12174: Recursive use of type-in-type results in infinite loop
by GHC 24 Oct '16

24 Oct '16

#12174: Recursive use of type-in-type results in infinite loop -------------------------------------+------------------------------------- Reporter: ezyang | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- Typechecking this module results in an infinite loop: {{{ {-# LANGUAGE DataKinds #-} {-# LANGUAGE ExistentialQuantification #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE TypeInType #-} module X where data V a data T = forall (a :: S). MkT (V a) data S = forall (a :: T). MkS (V a) }}} There's a mutually recursive reference so it should be rejected but maybe the check is not happening early enough (or the existing check is only for self-reference.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12174> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #12081: TypeInType Compile-time Panic
by GHC 24 Oct '16

24 Oct '16

#12081: TypeInType Compile-time Panic -------------------------------------+------------------------------------- Reporter: MichaelK | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I've been playing around with GHC 8.0.1-rc4 release and got a panic from the following (stripped down) code: {{{#!hs {-# LANGUAGE TypeInType #-} data Nat = Z | S Nat class C (n :: Nat) where type T n :: Nat f :: (a :: T n) }}} {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.0.0.20160421 for x86_64-apple-darwin): isInjectiveTyCon sees a TcTyCon T }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12081> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12386: Infinite loop when showing type family error
by GHC 24 Oct '16

24 Oct '16

#12386: Infinite loop when showing type family error -------------------------------------+------------------------------------- Reporter: elliottt | 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: -------------------------------------+------------------------------------- When attempting to load this code in ghci with ghc-8.0.1, I get an infinite loop while it attempts to display the error: {{{ {-# LANGUAGE TypeFamilies #-} class C a where type family F a t :: * type family T a :: * type T a = F a }}} {{{ catbug :: ~/Scratch/ast-experiment » ghci test.hs GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /Users/trevor/.ghci [1 of 1] Compiling Main ( test.hs, interpreted ) test.hs:7:14: error: }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12386> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #12618: Add saturated constructor applications to Core
by GHC 24 Oct '16

24 Oct '16

#12618: Add saturated constructor applications to Core -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- A long-standing performance bug in GHC is its behaviour on nested tuples. * The poster-child case is #5642. * The problem is that when you have a nested tuple application, e.g. `((4,True),('c','d'))`, the size of the type arguments grows quadratically with the expression size. This bites badly in some approaches to generic programming, which use nested tuples heavily. * It's explained in detail in Section 2.3 of [http://research.microsoft.com/en- us/um/people/simonpj/papers/variant-f/index.htm Scrap your type applications]. The same paper describes a solution, a modification of System F called System IF. It's neat, and I did once implement in in GHC. But it was quite complicated; most of the time the win was not big; and I don't know how it'd interact with casts, coercions, and type dependency in the latest version of GHC's Core. So here's another idea, which came up in converstion at ICFP'16: '''add a staturated constructor application to Core'''. So Core looks like {{{ data Expr v = Var v | App (Expr v) (Expr v) ... | ConApp DataCon [Expr v] -- NEW }}} Now I hate the idea of adding a new constructor to Core; I often brag about how few constructors it has. But the idea is this: * A `ConApp` is always saturated; think of it as an uncurried application. * Every data constructor has a wrapper Id. For simple constructors like `(:)`, the wrapper is just a curried version: {{{ (:) = /\a. \(x:a). \(y:[a]). (:) [x,y] }}} where the "`(:) [x,y]`" is just my concrete syntax for a `ConApp` node. * We are used to having an intro and elim form for each type former. So for `(->)` the intro form is `\x.e` and the elim form is `(e1 e2)`. For a data type like `Maybe`, the elim form is `case`, but what's the intro form? `ConApp` of course. * A `ConApp` mentions the `DataCon` explicitly, rather than having it buried inside the `IdDetails` of an `Id`, which somehow seems more honest. The proximate reason for doing this in the first place is to allow us to omit type arguments. Consider `Just True`. Curently we represent this as {{{ Var "Just" `App` Type boolTy `App` Var "True" }}} But with `ConApp` we can say {{{ ConApp "Just" [ConApp "True" []] }}} because it's easy to figure out the `boolTy` type argument from the argument. (We don't really have strings there, but you get the idea.) Can we omit ''all'' the type arguments? No: we can omit only those that appear free in any of the argument types. That is usally all of them (including existentials) but not always. Consider: {{{ data (,) a b where (,):: forall a b. a -> b -> (a,b) data [] a where [] :: forall a. [a] (:) :: forall a. a -> [a] -> [a] data Either a b where Left :: forall a b. a -> Either a b Right :: forall a b. b -> Either a b data (:=:) a b where Refl :: forall a b. (a~b) -> :=: a b data Foo where MkFoo :: a -> (a -> Int) -> Foo }}} For all of these data constructors except `[]` (nil), `Left` and `Right` we can omit all the type arguments, because we can recover them by simple matching against the types of the arguments. A very concrete way to think about this is how to implement {{{ exprType :: Expr Id -> Type exprType (Var v) = varType v exprType (Lam b e) = mkFunTy (varType b) (exprType e) exprType (App f a) = funResultTy (exprType f) ... exprType (ConApp con args) = mkTyConApp (dataConTyCon con) ??? }}} We know that the result type of type of a `ConApp` will be `T t1 ..tn` where `T` is the parent type constructor of the `DataCon`. But what about the (universal) type args `???`? We can get them from the types of the arguments `map exprType args`: * For `ConApp "(:)" [e1, e2]`, the type arument is just `exprType e1`. * For `ConApp "(:=:)" [e]`", we expect `exprType e` to return a type looking like `TyConApp "~" [t1, t2]`. Then `t1` and `t2` are the types we want. So matching is required. * What about an application of `Left`?? We need to recover two type args, but `exprType e1` gives us only one. So we must retain the other one in the application: `ConApp "Left" [Type ty2, e1]`. Similarly for the empty list. A simple once-and-for-all analyis on the `DataCon` will establish how to do the matching, which type args to retain, etc. Tradeoffs: * Pro: We can eliminate almost all type args of almost all data constructors; and for nested tuples we can eliminate all of them. * Pro: it's elegant having the intro/elim duality. * Pro: in GHC we often ask "is this expression a saturated constructor application?" (see `exprIsConApp_maybe`) and `ConApp` makes it easier to answer that question. * Pro: we do exactly this in types: we have `AppTy` and `TyConApp`. (In types a `TyConApp` is not required to be satureted, but we could review that choice.) * Con: adding a constructor is a big deal. In lots of places we'd end up saying {{{ f (App e1 e2) = App (f e1) (f e2) f (ConApp c es) = ConApp c (map f es) }}} In the olden days GHC's `App` had multiple arguments and the continual need to work over the list was a bit tiresome. Still `ConApp` is very simple and uniform; quite often adding `map` won't be difficult; and it may well be that constructors need to be treated differently anyway. * Con: it's not a general solution to the type-argument problem. See #9198 for example. System IF is the only general solution I know, but it seems like too big a sledgehammer. We'll only know if we try it. I estimiate that it would take less than a week to work this change through all of GHC. 90% of it is routine. Other possibly-relevant tickets are #8523, #7428, #9630. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12618> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 37

[GHC] #12427: Type inference regression with RankNTypes (GHC 8.1)
by GHC 24 Oct '16

24 Oct '16

#12427: Type inference regression with RankNTypes (GHC 8.1) -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: RankNTypes | 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: -------------------------------------+------------------------------------- The following module compiles fine with ghc-8.0.1: {{{#!hs {-# LANGUAGE RankNTypes #-} module Acquire where newtype Acquire a = Acquire {unAcquire :: (forall b. b -> b) -> IO a} instance Functor Acquire where fmap = undefined instance Applicative Acquire where pure = undefined (<*>) = undefined instance Monad Acquire where Acquire f >>= g' = Acquire $ \restore -> do x <- f restore let Acquire g = g' x -- let g = unAcquire (g' x) g restore }}} HEAD (83e4f49577665278fe08fbaafe2239553f3c448e, ghc-8.1.20160720) reports: {{{ Acquire.hs:17:21: error: • Couldn't match expected type ‘t’ with actual type ‘(forall b1. b1 -> b1) -> IO b’ ‘t’ is a rigid type variable bound by the inferred type of g :: t at Acquire.hs:17:13-28 • In the pattern: Acquire g In a pattern binding: Acquire g = g' x In the expression: do { x <- f restore; let Acquire g = g' x; g restore } • Relevant bindings include g' :: a -> Acquire b (bound at Acquire.hs:15:19) (>>=) :: Acquire a -> (a -> Acquire b) -> Acquire b (bound at Acquire.hs:15:15) }}} This example is reduced from the `recourcet` package on Hackage, module `Data.Acquire.Internal`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12427> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7