November 2016 - ghc-tickets

[GHC] #9805: Use TrieMaps to speed up type class instance lookup
by GHC 17 Jul '17

17 Jul '17

#9805: Use TrieMaps to speed up type class instance lookup -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.9 checker) | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Currently, type class instance resolution is performed by doing a map lookup by type class, and then linearly matching against every instance. This is not great, and for a while, simonpj has been keen on using the TrieMap data structure in GHC, which has been previously used to implement a map from CoreExprs to various things (e.g. for CSE). What makes this a little tricky is that instance lookup isn't intended to be an exact match: we should unify so-called template variables and provide a substitution; furthermore, there may be multiple matches. After some prototyping, I think we should be able to make this work. The primary refactoring we have to do is *maintain the key associated with an entry in a TrieMap*. Unlike the current uses of TrieMaps, where it's acceptable to lose the underlying key associated with an entry in the TrieMap, we need to know the key when doing unification, because it may be reported in the substitution. There are a few knock-on effects of this: * We should add a method `foldWithKeyTM :: (Key m -> a -> b -> b) -> m a -> b -> b` to the `TrieMap` type class. * We need a variant of `UniqFM` which tracks the original key that was used. I propose we name it `UniqKM` (unique key map). A number of implementations of `TrieMap` need to be adjusted to use this instead of `UniqFM`. * Why can't we just represent keyed TrieMaps as `TypeMap (Type, a)`? It might be possible. An insurmountable difficulty would be if we need to know the partial key PRIOR to having finished traversing the TrieMap; however, for the parts of the unification algorithm I've implemented, this does not seem to be the case. The primary actual difficulty is that `Type` uses a named representation, whereas `TypeMap` keys are on-the-fly deBruijn numbered. There would at least be some annoying fiddliness. * Reversing the deBruijn numbered key into a `Type` is a bit goofy. Essentially, you need the reverse of the current `CmEnv`: a mapping from de Bruijn levels to the `Var` you've decided to allocate. (I've called this `CfEnv` in my prototype) * When we represent a TrieMap binder, we have to put the binder map on the OUTSIDE, as opposed to the inside as it is currently. Otherwise, we can't update the `CfEnv` with the new mapping before making the recursive call to fold-with-key. I'll attach the standalone Haskell file I used to prototype this, wherein I copy-pasted a lot of Haskell from GHC's source and implemented fuzzy map on a simplified version of `Type`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9805> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #12089: :kind command allows unsaturated type family,
by GHC 12 Jul '17

12 Jul '17

#12089: :kind command allows unsaturated type family, -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- {{{#!hs data A = B type family F a where F B = String infixr 9 `Compose` class (f (g x)) => (f `Compose` g) x instance (f (g x)) => (f `Compose` g) x }}} GHCi accepts {{{ ghci> :kind Compose Eq F Compose Eq F :: A -> Constraint }}} but when used in code it gets rejected {{{ -- tvI6.hs:13:8-33: error: … -- • The type family ‘F’ should have 1 argument, but has been given none -- • In the type signature: -- foo :: (Eq `Compose` F) a => String -- Compilation failed. foo :: (Eq`Compose`F) a => String foo = undefined }}} Bug? Version 8.0.0.20160511 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12089> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8346: Rank 1 type signature still requires RankNTypes
by GHC 11 Jul '17

11 Jul '17

#8346: Rank 1 type signature still requires RankNTypes ----------------------------+---------------------------------------------- Reporter: | Owner: tinctorius | Status: new Type: bug | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects valid program Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: #2605 | ----------------------------+---------------------------------------------- When trying to figure out which type variable names are *actually* bound in `ScopedTypeVariables`, I tried floating `forall`s into the covariant argument of the function type. Essentially, I ran into the problem that programs like the following are rejected: {{{ #!hs {-# LANGUAGE ExplicitForAll #-} tuple :: forall a. a -> (forall b. b -> (a, b)) tuple = (,) }}} The message is as follows: {{{ Main.hs:2:10: Illegal polymorphic or qualified type: forall b. b -> (a, b) Perhaps you intended to use -XRankNTypes or -XRank2Types In the type signature for `tuple': tuple :: forall a. a -> (forall b. b -> (a, b)) }}} As far as I know, the rank of a type is defined by how deep quantifiers are nested in contravariant parts of that type. Or something like that. Also, as far as I know, `forall a. a -> (forall b. b -> (a, b))` is equivalent to `forall a b. a -> b -> (a, b)`, and more importantly, both are rank-1 polymorphic. There should be no need to use extensions that allow higher-ranked polymorphism. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8346> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12390: List rules for `Coercible` instances
by GHC 11 Jul '17

11 Jul '17

#12390: List rules for `Coercible` instances -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- `:info` on [https://downloads.haskell.org/~ghc/7.8.2/docs/html/libraries/base-4.7.0.0 /Data-Coerce.html#t:Coercible Data.Coerce.Coercible] doesn't display any instances, it's a special class so it should be special-cased {{{ ghci> :i Coercible type role Coercible representational representational class a ~R# b => Coercible (a :: k) (b :: k) -- Defined in ‘GHC.Types’ }}} The base case would be easy to display: {{{#!hs instance Coercible a a -- Generated on the fly }}} but it's trickier to describe the … instance succinctly: {{{#!hs instance Coercible b b' => Coercible (D a b c) (D a b' c') }}} same for newtypes. ---- Maybe it's better to list concrete examples {{{#!hs coerce @(Reader _ _) :: Reader a b -> (a -> Identity b) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12390> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #10150: Suppress orphan instance warning per instance
by GHC 11 Jul '17

11 Jul '17

#10150: Suppress orphan instance warning per instance -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Milestone: Priority: low | Version: 7.11 Component: Compiler | Operating System: Unknown/Multiple (Type checker) | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- In the same way we have overlapping/incoherent instance pragmas which can be applied on a per instance basis, it would be good to have a `-fno-warn- orphan-instance` pragma which can be applied on a per-instance basis. Annoyingly, there is not an obvious syntax to use for this case, since SOP for a module with orphan instances is `{-# GHC_OPTIONS -fno-warn-orphans #-}` -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10150> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11954: Associated pattern synonyms not included in haddock
by GHC 07 Jul '17

07 Jul '17

#11954: Associated pattern synonyms not included in haddock -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc3 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: -------------------------------------+------------------------------------- Running haddock on: {{{#!hs {-# LANGUAGE PatternSynonyms #-} module Foo ( A(P) ) where data A a = A pattern P = A }}} Just gives a data type A with no constructors, and no mention of the associated pattern synonym P. Attached is a patch for haddock that prints associated patterns as GADT constructors -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11954> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #10648: Some 64-vector SIMD primitives are absolutely useless
by GHC 03 Jul '17

03 Jul '17

#10648: Some 64-vector SIMD primitives are absolutely useless -------------------------------------+------------------------------------- Reporter: mniip | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The primitives `packInt8X64#`, `packWord8X64#`, `unpackInt8X64#`, `unpackWord8X64#` cannot be used because their types include unboxed 64-tuples, but any haskell code using them does not compile due to the 62-tuple limitation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10648> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12610: Emit tab warning promptly
by GHC 03 Jul '17

03 Jul '17

#12610: Emit tab warning promptly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs p = let x = 4 [tab]y = 5 in 12 }}} produces `error: parse error on input ‘y’` and nothing else. The problem is caused by a tab appearing to the user to line up `x` with `y` but actually placing `y` in the wrong column. The user typically will scratch their head and then post a question on StackOverflow. There they'll be told to use `-fwarn-tabs`, but ''that option won't help'' (and it's probably already on) because GHC will exit with a parse error before it gets around to giving the warning. I suspect the solution is probably to emit the tab warning in the lexer, but one of the parsing gurus will probably know better. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12610> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #12203: Allow constructors on LHS of (implicit) bidirectional pattern synonym
by GHC 01 Jul '17

01 Jul '17

#12203: Allow constructors on LHS of (implicit) bidirectional pattern synonym -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Priority: low | 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: -------------------------------------+------------------------------------- Inspired by the recent Ghostbuster paper http://www.cs.ox.ac.uk/people/timothy.zakian/ghostbuster.pdf , I was experimenting with using pattern synonyms to simulate GADTs. In the process, I noticed that we should be able to generalize the implicit bidirectional synonyms to allow constructors on the LHS. Consider this program: {{{ {-# LANGUAGE KindSignatures #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE PatternSynonyms #-} {-# LANGUAGE ViewPatterns #-} {-# LANGUAGE TypeOperators #-} {-# OPTIONS_GHC -fwarn-incomplete-patterns #-} module GhostBuster where import GHC.TypeLits newtype Vec a (n :: Nat) = Vec { unVec :: [a] } pattern VNil :: Vec a 0 pattern VNil = Vec [] pattern VCons :: a -> Vec a n -> Vec a (n + 1) pattern VCons x xs <- Vec (x : (Vec -> xs)) where VCons x (Vec xs) = Vec (x : xs) headVec :: Vec a (n + 1) -> a headVec (VCons x _) = x }}} In effect, we simulate a vector GADT using pattern synonyms to handle the newtype `Vec`. I would like it if I could specify the `VCons` pattern more simply, as just: {{{ pattern VCons :: a -> Vec a n -> Vec a (n + 1) pattern VCons x (Vec xs) = Vec (x : xs) }}} And GHC would infer the correct pattern (the constructor can be read off immediately), automatically replacing occurrences of `xs` with a view pattern that reconstructs the constructors that were stripped off on the LHS. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12203> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #9588: Add `MonadPlus {IO, Either e}` and `Alternative (Either e)` instances
by GHC 29 Jun '17

29 Jun '17

#9588: Add `MonadPlus {IO,Either e}` and `Alternative (Either e)` instances -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The following 3 instances are currently Orphans in `transformers` but shall be defined in `base` instead: {{{#!hs instance MonadPlus IO instance MonadPlus (Either e) instance Alterantive (Either e) }}} This proposal by SPJ already passed the CLC back in April and only needs implementing. I'll submit a patch shortly to Phab -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9588> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11