February 2015 - ghc-tickets

[GHC] #9596: Create monoidal category framework for arrow desugarer
by GHC 03 Apr '17

03 Apr '17

#9596: Create monoidal category framework for arrow desugarer -------------------------------------+------------------------------------- Reporter: spacekitteh | Owner: Type: task | spacekitteh Priority: normal | Status: new Component: GHC API | Milestone: 7.10.1 Keywords: | Version: Architecture: Unknown/Multiple | Operating System: Difficulty: Project (more | Unknown/Multiple than a week) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I'm going to put it into a GHC namespace (GHC.Arrows.Experimental, perhaps) and put instances for Arrow and such in there as well. In a later ticket I'll work on the desugarer, converting erverything into SMC combinators rather than Arrow combinators. The basic design is [blog.spacekitteh.moe/posts/new-monoidal-cats.html here] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9596> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #8501: Improve error message when using rec/mdo keyword without RecursiveDo extention.
by GHC 29 Mar '17

29 Mar '17

#8501: Improve error message when using rec/mdo keyword without RecursiveDo extention. -------------------------------------+------------------------------------- Reporter: shelarcy | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #3968 | -------------------------------------+------------------------------------- GHC shows unhelpful error message when using rec keyword and/or mdo keyword without RecursiveDo extention. {{{ module NoRecursiveDo where foo = do rec str <- return "foo" putStrLn str }}} {{{ $ ghc -c NoRecursiveDo.hs NoRecursiveDo1.hs:4:5: Parse error in pattern: rec }}} {{{ module NoRecursiveDo2 where bar = mdo str <- return "bar" putStrLn str }}} {{{ $ ghc -c NoRecursiveDo2.hs NoRecursiveDo2.hs:4:9: parse error on input `<-' }}} {{{ module NoRecursiveDo3 where baz = mdo putStrLn "baz" }}} {{{ $ ghc -c NoRecursiveDo3.hs NoRecursiveDo3.hs:3:7: Not in scope: `mdo' Perhaps you meant `mod' (imported from Prelude) }}} I think that GHC should suggest to use RecursiveDo extention when using mdo/rec keyword. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8501> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9418: Warnings about "INLINE binder is (non-rule) loop breaker"
by GHC 27 Mar '17

27 Mar '17

#9418: Warnings about "INLINE binder is (non-rule) loop breaker" -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Gabor rightly complains: I see literally ''thousands'' of these warnings (in yesterday's and) today's bootstraps: {{{ HC [stage 1] libraries/base/dist-install/build/GHC/Base.o *** Core Lint warnings : in result of Desugar (after optimization) *** {-# LINE 261 "libraries/base/GHC/Base.lhs #-}: Warning: [RHS of $c>>_arr :: forall r_agf a_adQ b_adR. (r_agf -> a_adQ) -> (r_agf -> b_adR) -> r_agf -> b_adR] INLINE binder is (non-rule) loop breaker: $c>>_arr {-# LINE 632 "libraries/base/GHC/Base.lhs #-}: Warning: [RHS of $c>>_apH :: forall a_adQ b_adR. GHC.Types.IO a_adQ -> GHC.Types.IO b_adR -> GHC.Types.IO b_adR] INLINE binder is (non-rule) loop breaker: $c>>_apH }}} }}} This is clearly unsatisfactory, because it is unsettling, and perhaps conceals more important warnings. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9418> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9701: GADTs not specialized properly
by GHC 21 Mar '17

21 Mar '17

#9701: GADTs not specialized properly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Runtime Blocked By: | performance bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- This has probably been raised before, but I can't find a ticket. If I write {{{#!hs data Silly a where Silly :: Ord a => a -> Silly a isItSilly :: a -> Silly a -> Bool isItSilly a (Silly x) = a < x isItSillyInt :: Int -> Silly Int -> Bool isItSillyInt = isItSilly }}} then I get {{{ isItSilly isItSilly = \ @ a_aBq eta_B2 eta1_B1 -> case eta1_B1 of _ { Silly $dOrd_aBs x_aAy -> < $dOrd_aBs eta_B2 x_aAy } isItSillyInt isItSillyInt = isItSilly }}} Although GHC knows that `eta_B2` is an `Int`, and `x_aAy` therefore must be one as well, it looks up the `<` method in the `eta1_B1` dictionary instead of just using `ltInt`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9701> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #8751: Show parenthesised output of expressions in ghci
by GHC 20 Mar '17

20 Mar '17

#8751: Show parenthesised output of expressions in ghci ------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Iceland_jack Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Operator fixity can be a source of bugs (even for experienced users!),[#point1 (1)] precedence levels may vary between languages and then there are user-defined operators. Attached is a patch for a ghci command allowing users to quickly parenthesise expressions as a sanity check (and as an alternative to using :info and parsing the result yourself). The command itself is activated with `:paren`: {{{ ghci> :paren 2 + 10 * 4 / 3 2 + ((10 * 4) / 3) ghci> :paren \a b → a == b || b && a == (b == a) || b \ a b -> (a == b) || ((b && (a == (b == a))) || b) ghci> :paren 5 + 1 `mod` 2 5 + (1 `mod` 2) ghci> :paren 5 * 1 `mod` 2 (5 * 1) `mod` 2 }}} A friend of mine also pointed out that this could eventually be integrated into `haskell-mode` where the user could temporarily replace an expression with a parenthesised version or have different colours indicate different levels of logical nesting. [=#point1 (1)] [http://www.knosof.co.uk/cbook/accu06.html Developer beliefs about binary operator precedence] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8751> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #8255: GC Less Operation
by GHC 07 Mar '17

07 Mar '17

#8255: GC Less Operation ------------------------------+-------------------------------------------- Reporter: sirinath | Owner: Type: feature | Status: new request | Milestone: Priority: highest | Version: 7.6.3 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: Runtime performance bug Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- Hi, Is it possible to eliminated GC through Automatic Reference Counting (ARC) like in Objective C / Clang. S -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8255> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #9729: GHCi accepts invalid programs when recompiling
by GHC 01 Mar '17

01 Mar '17

#9729: GHCi accepts invalid programs when recompiling -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: GHC Blocked By: | accepts invalid program Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Here's what's happening: Module A imports module B. Module B contains a function with constraints that are '''required''' to compile module B. If I load module A in GHCi, I can remove some (required) constraints on the function in module B and GHCi will successfully reload module B. My example uses the [https://hackage.haskell.org/package/syntactic syntactic] library. I attempted to recreate the situation I just described without syntactic, but I was unsuccessful. Module A.hs: {{{ #!haskell module A where import B import Data.Syntactic.Sugar.BindingT () main = print "hello" }}} Module B.hs: {{{ #!haskell {-# LANGUAGE GADTs, TypeOperators, FlexibleContexts #-} module B where import Data.Syntactic data Let x where Let :: Let (a :-> (a -> b) :-> Full b) share :: (Let :<: sup, sup ~ Domain b, sup ~ Domain a, Internal (a -> b) ~ (Internal a -> Internal b), -- remove me Syntactic a, Syntactic b, Syntactic (a -> b), SyntacticN (a -> (a -> b) -> b) (ASTF sup (Internal a) -> ASTF sup (Internal (a -> b)) -> ASTF sup (Internal b))) => a -> (a -> b) -> b share = sugarSym Let }}} Here's a terminal transcript: {{{ $ ghci A [1 of 2] Compiling B ( testsuite/B.hs, interpreted ) [2 of 2] Compiling A ( testsuite/A.hs, interpreted ) Ok, modules loaded: A, B. > (Now remove the constraint from B and save. This *should* break module B) > :r [1 of 2] Compiling B ( testsuite/B.hs, interpreted ) Ok, modules loaded: A, B. > :q $ ghci B [1 of 2] Compiling B ( testsuite/B.hs, interpreted ) testsuite/B.hs:21:9: Could not deduce (Internal (a -> b) ~ (Internal a -> Internal b)) }}} If I had to guess what's going on, it's that GHCi is remembering the instance that A imports from BindingT: {{{ instance (...) => Syntactic (a -> b) where type Internal (a -> b) = Internal a -> Internal b }}} This instance implies the constraint that module B needs, however it should never be visible to module B. GHCi seems to be ignoring that and using the instance to recompile module B. When compiling from scratch, module B is compiled first, so of course the instance (and therefore the constraint) are not visible. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9729> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9131: Experiment with a dedicated solver for Coercible
by GHC 01 Mar '17

01 Mar '17

#9131: Experiment with a dedicated solver for Coercible ------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: low | 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: | ------------------------------------+------------------------------------- This is something that I might want to do some time; it should not distract us from working and improving the current design and implementation. But I think it should be explored. Currently `Coercible` appears as a type class, we have instances to explain it, and use the existing solver to solve them. The last part sometimes causes problems: * the order the instances are tried matters, there might be dead ends (#9117) * recursive newtypes are not handled as good as they could be. It would be worth exploring if a dedicated solver for `Coercible` constraints could solve these issues. It could replace the existing `getCoercibleInst`. Given a constraint `Coercible s t` it would solve it completely, do nothing or (and this is not planned out yet) return some sufficient and in some sense primitive constraint that should appear in inferred type signatures etc. Ideally we could still explain `Coercible` in terms of the instances written in the ICFP’14 paper, and simply state „GHC will find a solution using these instances, if there are any.“ instead of „The usual solver is employed, it might run into dead ends (or not, hard to tell).“ When tackling this task, I should do something that I keep postponing (because I don’t like to admit my lack of knowlege about that) but I think is really important: What are the theoretical properties of solving `Coercible` constraints? Is it even decidable? Semi decidable? Are there existing standard algorithms? How does this relate to SMT solving? And why don’t I know these things... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9131> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9117: Coercible constraint solver misses one
by GHC 01 Mar '17

01 Mar '17

#9117: Coercible constraint solver misses one ------------------------------------+------------------------------------- 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 {{{ import Data.Type.Coercion import Data.Coerce eta :: Coercible f g => Coercion (f a) (g a) eta = Coercion }}} I get {{{ Could not coerce from ‘f a’ to ‘g a’ because ‘f a’ and ‘g a’ are different types. arising from a use of ‘Coercion’ from the context (Coercible f g) bound by the type signature for eta :: Coercible f g => Coercion (f a) (g a) at /Users/rae/temp/Roles.hs:6:8-44 In the expression: Coercion In an equation for ‘eta’: eta = Coercion }}} But, this coercion is easily expressible in Core. If `(co :: f ~R# g)` then `(co <a> :: f a ~R# g a)`, where `<a>` is the notation for a reflexivity coercion for the type `a`. The constraint solver should be able to do this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9117> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 35

[GHC] #8779: Exhaustiveness checks for pattern synonyms
by GHC 28 Feb '17

28 Feb '17

#8779: Exhaustiveness checks for pattern synonyms -------------------------------------------+------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- Pattern synonyms are great, as they decouple interface from implementation. Especially if #8581 is also implemented, it should be possible to change a type completely while retaining the existing interface. Exciting! Another missing piece is exhaustiveness checks. Given this pattern {{{ initLast [] = Nothing initLast xs = Just (init xs, last xs) pattern xs ::: x <- (initLast -> Just (xs,x)) }}} we want the compiler to tell the programmer that {{{ f [] = ... f (xs ::: x) = ... }}} is complete, while {{{ g (xs ::: x) = ... }}} is not. With view pattern directly, this is impossible. But the programmer did not write view patterns! So here is what I think might work well, inspired by the new `MINIMAL` pragma: We add a new pragma `COMPLETE_PATTERNS` (any ideas for a shorter name). The syntax is essentially the same as for `MINIMAL`, i.e. a boolean formula, with constructors and pattern synonyms as atoms. In this case. {{{ {-# COMPLETE_PATTERNS [] && (:::) #-} }}} Multiple pragmas are obviously combined with `||`, and there is an implicit `{-# COMPLETE_PATTERNS [] && (:) #-}` listing all real data constructors. When checking for exhaustiveness, this would be done before unfolding view patterns, and for `g` above we get a warning that `[]` is not matched. Again, the implementation is very much analogous to `MINIMAL`. Clearly, a library author can mess up and give wrong `COMPLETE_PATTERNS` pragmas. I think that is ok (like with `MINIMAL`), and generally an improvement. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8779> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 58