October 2017 - ghc-tickets

[GHC] #13652: Add integer division to GHC.TypeLits
by GHC 08 Oct '17

08 Oct '17

#13652: Add integer division to GHC.TypeLits -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: (none) 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: -------------------------------------+------------------------------------- GHC.TypeLits currently lacks integer division type families and I can't see why. What is the reason for not having these methods of the `Integral` class at type level: {{{#!hs quot rem div mod quotRem divMod }}} ? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13652> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #14320: Brackets change meaning of value-constructor type
by GHC 08 Oct '17

08 Oct '17

#14320: Brackets change meaning of value-constructor type -------------------------------------+------------------------------------- Reporter: nr | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Type checker) | Keywords: GADT, | Operating System: Linux existential type | Architecture: x86_64 | Type of failure: GHC rejects (amd64) | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Some legacy code from GHC 7.x does not compile under 8.0 or 8.2. The issue seems to be that I have wrapped brackets around the type of a value constructor, and 8.x does not want to see those brackets. To try to learn if this change was deliberate, I have searched the release notes. Found nothing. I am hoping this is an actual bug, as I would hope to be able to wrap any type or term in brackets without changing its meaning (except of course for fixity). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14320> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #14256: GHCi is faster than compiled code
by GHC 06 Oct '17

06 Oct '17

#14256: GHCi is faster than compiled code -------------------------------------+------------------------------------- Reporter: mpickering | 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: -------------------------------------+------------------------------------- A stackoverflow user Milad Zahedi reports that running his code in GHCi is 50x faster than compiling it and running the compiled binary. > Today I did little benchmarking on my local machine to compare plain text speed of different Haskell web frameworks, and I noticed something strange. Almost all the frameworks that I tested, performed better when they were run from GHCi compared to compiled version. here are my results > {{{ +------------------------------------ |framework| GHCi rpm | compiled rpm +---------+------------+------------- |snap | 8000 | 150 +---------+------------+------------- |yesod | 6000 | 2500 +---------+------------+------------- |scotty | 22000 | 9500 +---------+------------+------------- |servant | 17000 | 8500 +---------+------------+------------- |spock | 3300 | 2700 +---------+------------+------------- }}} > I know that these numbers do not reflect on these frameworks speed, since they are not well tuned or optimized, but my question is why are these frameworks performing better when launched from GHCi. Am I doing something wrong ? > > in order to build them I simply run stack build The benchmarks are from https://github.com/miladz68/haskell-webframework- comparison This ticket is to verify and investigate these claims. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14256> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14327: Type error in program caused by unrelated definition
by GHC 06 Oct '17

06 Oct '17

#14327: Type error in program caused by unrelated definition -------------------------------------+------------------------------------- Reporter: lexi.lambda | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- ''Adapted from [https://stackoverflow.com/q/46595162/465378 this Stack Overflow question].'' The following program raises two type errors: {{{#!hs import Prelude hiding (readFile, writeFile) import Control.Monad.Free import Data.Functor.Sum data FileSystemF a = ReadFile FilePath (String -> a) | WriteFile FilePath String a deriving (Functor) data ConsoleF a = WriteLine String a deriving (Functor) data CloudF a = GetStackInfo String (String -> a) deriving (Functor) type App = Free (Sum FileSystemF (Sum ConsoleF CloudF)) readFile :: FilePath -> App String readFile path = liftF (InL (ReadFile path id)) writeFile :: FilePath -> String -> App () writeFile path contents = liftF (InL (WriteFile path contents ())) writeLine :: String -> App () writeLine line = liftF (InR (WriteLine line ())) }}} {{{ /private/tmp/free-sandbox/src/FreeSandbox.hs:26:27: error: • Couldn't match type ‘ConsoleF’ with ‘Sum ConsoleF CloudF’ arising from a functional dependency between constraints: ‘MonadFree (Sum FileSystemF (Sum ConsoleF CloudF)) (Free (Sum FileSystemF (Sum ConsoleF CloudF)))’ arising from a use of ‘liftF’ at src/FreeSandbox.hs:26:27-66 ‘MonadFree (Sum FileSystemF ConsoleF) (Free (Sum FileSystemF (Sum ConsoleF CloudF)))’ arising from a use of ‘liftF’ at src/FreeSandbox.hs:29:18-48 • In the expression: liftF (InL (WriteFile path contents ())) In an equation for ‘writeFile’: writeFile path contents = liftF (InL (WriteFile path contents ())) | 26 | writeFile path contents = liftF (InL (WriteFile path contents ())) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ /private/tmp/free-sandbox/src/FreeSandbox.hs:29:18: error: • Couldn't match type ‘Sum ConsoleF CloudF’ with ‘ConsoleF’ arising from a functional dependency between: constraint ‘MonadFree (Sum FileSystemF ConsoleF) (Free (Sum FileSystemF (Sum ConsoleF CloudF)))’ arising from a use of ‘liftF’ instance ‘MonadFree f (Free f)’ at <no location info> • In the expression: liftF (InR (WriteLine line ())) In an equation for ‘writeLine’: writeLine line = liftF (InR (WriteLine line ())) | 29 | writeLine line = liftF (InR (WriteLine line ())) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} The second of the two errors (the one on line 29) makes sense—it’s an error I would expect (there is a missing use of `InL`). However, the first error seems incorrect, as the definition of `writeFile` is, in fact, well- typed. In fact, if the definition of `writeLine` is commented out, the program typechecks! It gets weirder: if the definition of `writeLine` is moved in between the definitions of `readFile` and `writeFile`, then the unexpected error is reported for the definition of ''`readFile`'', and if `writeLine` is moved above both of them, then the error isn’t reported at all! This implies that a well-typed function (`writeFile`) can actually become ill-typed after the addition of an unrelated, ill-typed definition (`writeLine`). That seems like a bug to me. I was able to reproduce this issue on GHC 7.10.3, 8.0.2, and 8.2.1. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14327> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14300: FreeBSD 10.3 toolchain is terribly broken
by GHC 06 Oct '17

06 Oct '17

#14300: FreeBSD 10.3 toolchain is terribly broken -------------------------------------+------------------------------------- Reporter: bgamari | 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: #13974 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- == `ld.bfd` with `SplitSections=NO` Fails in the final bindist test with, {{{ /usr/bin/install -c -m 755 libraries/gen_contents_index "/usr/home/ben /bin- dist-8.2.1.20170929-FreeBSD/test/inst/share/doc/ghc-8.2.1.20170929/html/libraries/" [1 of 1] Compiling Main ( /usr/home/ben/bin- dist-8.2.1.20170929-FreeBSD/test/hi.hs, /usr/home/ben/bin- dist-8.2.1.20170929-FreeBSD/test/hi.o ) Linking /usr/home/ben/bin-dist-8.2.1.20170929-FreeBSD/test/hi ... /usr/bin/ld: Base__199.o: access beyond end of merged section (-24) /usr/bin/ld: Base__201.o: access beyond end of merged section (-24) ... }}} == `ld.bfd` with `SplitSections=YES` fails with, {{{ ... }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14300> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14326: Panic on COMPLETE pragma with mismatched type variable order
by GHC 06 Oct '17

06 Oct '17

#14326: Panic on COMPLETE pragma with mismatched type variable order -------------------------------------+------------------------------------- Reporter: dailectic | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The motivating example is to allow patterns with phantom types to interact nicely with TypeApplications, so in the below we can do `L @Int :: a -> L a Int` to specify the phantom. {{{#!hs data E a b = L' a | R b pattern L :: forall b a. a -> E a b pattern L a = L' a {-# COMPLETE L, R #-} }}} The compiler balks {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-unknown-linux): mkOneConFull: Not TyConApp: c_a50V Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/deSugar/Check.hs:976:30 in ghc:Check Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14326> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #14279: Type families interfere with specialisation rewrite rules
by GHC 05 Oct '17

05 Oct '17

#14279: Type families interfere with specialisation rewrite rules -------------------------------------+------------------------------------- Reporter: IvanTimokhin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- Consider the attached file, in particular the function {{{#!hs vinr :: Length as -> VSum bs -> VSum (as ++ bs) }}} its specialised version {{{#!hs vinr0 :: Length '[] -> VSum as -> VSum as }}} and the rewrite rule {{{#!hs {-# RULES "vinr/0" vinr = vinr0 #-} }}} According to [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_ext… the relevant section of GHC user guide], `vinr` should be replaced with `vinr0` whenever the types match. However, the resulting Core for `test` contains the following (compiled with `ghc -O2`): {{{#!hs Test.test1 = case extractIdx @ 'Z @ '[Int] @ Int (Test.$WIZ @ Int @ '[]) Test.test2 of { Left other_aZf -> Test.$wvinl @ Length @ '[Int] @ (Remove 'Z '[Int]) other_aZf; Right x_aZg -> vinr @ (Remove 'Z '[Int]) @ '[Int] (Test.$WLZ `cast` ((Length (Sym (Test.D:R:Remove[0] <Int>_N <'[]>_N)))_R :: (Length '[] :: *) ~R# (Length (Remove 'Z '[Int]) :: *))) (Test.VInL @ '[Int] @ Int @ '[] @~ (<'[Int]>_N :: ('[Int] :: [*]) GHC.Prim.~# ('[Int] :: [*])) x_aZg) } }}} So the rule never fires, and `vinr` is still there, even though it is directly applied to `LZ :: Length '[]`. My dilettante analysis is that, for some reason, GHC keeps the `Remove 'Z '[Int]` as-is, not evaluating it to `'[]`, and, since the types don't match //syntactically//, doesn't apply the rule. In particular, if I replace type families with classes with functional dependencies, the rule fires as expected. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14279> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14222: Simple text fusion example results in rather duplicative code
by GHC 05 Oct '17

05 Oct '17

#14222: Simple text fusion example results in rather duplicative code -------------------------------------+------------------------------------- Reporter: bgamari | 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: -------------------------------------+------------------------------------- Consider this program, {{{#!hs module T14221 where import Data.Text as T isNumeric :: Text -> Bool isNumeric t = T.all isNumeric' t && T.any isNumber t where isNumber c = '0' <= c && c <= '9' isNumeric' c = isNumber c || c == 'e' || c == 'E' || c == '.' || c == '-' || c == '+' }}} Compiling with `-O` results in over 1 kilobyte of assembler. After looking at the simplified Core the issue becomes apparent: the case analysis of `isNumeric'` is duplicated six times, {{{#!hs case ww4_X2zB of { __DEFAULT -> GHC.Types.False; '+'# -> jump $wloop_all_s2z2 (GHC.Prim.+# ww3_s2z0 2#); '-'# -> jump $wloop_all_s2z2 (GHC.Prim.+# ww3_s2z0 2#); '.'# -> jump $wloop_all_s2z2 (GHC.Prim.+# ww3_s2z0 2#); 'E'# -> jump $wloop_all_s2z2 (GHC.Prim.+# ww3_s2z0 2#); 'e'# -> jump $wloop_all_s2z2 (GHC.Prim.+# ww3_s2z0 2#) }; }}} It seems to me that we would ideally try to share this bit. Of course, this may be quite tricky to do in practice. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14222> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #14316: Precedence of type-level operators
by GHC 05 Oct '17

05 Oct '17

#14316: Precedence of type-level operators -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: precedence | Operating System: Unknown/Multiple TypeOperators DataKinds | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `a ': b ~ c ': d` seems to be parsed as `a ': (b ~ (c ': d))`. This is kind of unfortunate; It seems to me that (~) having a lower precedence would make more sense, i.e. have it parse as `(a ': b) ~ (c ': d)`. What //are// the precedences of (~) and XDataKind-lifted operators? The userguide mentions precedences when discussing TypeOperators, but not in combination with DataKinds, or the type-equality-constraint. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14316> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14322: Simplifying an instance context makes a rewrite rule no longer typecheck
by GHC 05 Oct '17

05 Oct '17

#14322: Simplifying an instance context makes a rewrite rule no longer typecheck -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Type checker) | Keywords: | 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: -------------------------------------+------------------------------------- This code (taken from the `reducers` package) compiles: {{{#!hs {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE MultiParamTypeClasses #-} import Prelude (Applicative(..), Functor(..), (.)) class Semigroup m where (<>) :: m -> m -> m class Semigroup m => Reducer c m where snoc :: m -> c -> m newtype Traversal f = Traversal { getTraversal :: f () } instance Applicative f => Semigroup (Traversal f) where Traversal a <> Traversal b = Traversal (a *> b) instance Applicative f => Reducer (f a) (Traversal f) where Traversal a `snoc` b = Traversal (() <$ (a *> b)) snocTraversal :: Reducer (f ()) (Traversal f) => Traversal f -> f () -> Traversal f snocTraversal a = (<>) a . Traversal {-# RULES "snocTraversal" snoc = snocTraversal #-} }}} But on GHC 8.2.1 and later, it gives this warning: {{{ GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:21:18: warning: [-Wsimplifiable-class-constraints] • The constraint ‘Reducer (f ()) (Traversal f)’ matches an instance declaration instance Applicative f => Reducer (f a) (Traversal f) -- Defined at Bug.hs:18:10 This makes type inference for inner bindings fragile; either use MonoLocalBinds, or simplify it using the instance • In the type signature: snocTraversal :: Reducer (f ()) (Traversal f) => Traversal f -> f () -> Traversal f | 21 | snocTraversal :: Reducer (f ()) (Traversal f) => Traversal f -> f () -> Traversal f | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} I decided to follow GHC's orders and reduce the `Reducer (f ()) (Traversal f)` context to just `Applicative f`: {{{#!hs {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE MultiParamTypeClasses #-} import Prelude (Applicative(..), Functor(..), (.)) class Semigroup m where (<>) :: m -> m -> m class Semigroup m => Reducer c m where snoc :: m -> c -> m newtype Traversal f = Traversal { getTraversal :: f () } instance Applicative f => Semigroup (Traversal f) where Traversal a <> Traversal b = Traversal (a *> b) instance Applicative f => Reducer (f a) (Traversal f) where Traversal a `snoc` b = Traversal (() <$ (a *> b)) snocTraversal :: Applicative f => Traversal f -> f () -> Traversal f snocTraversal a = (<>) a . Traversal {-# RULES "snocTraversal" snoc = snocTraversal #-} }}} But after doing so, the file no longer typechecks! {{{ GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:23:34: error: • Could not deduce (Applicative f) arising from a use of ‘snocTraversal’ from the context: Reducer (f ()) (Traversal f) bound by the RULE "snocTraversal" at Bug.hs:23:11-46 Possible fix: add (Applicative f) to the context of the RULE "snocTraversal" • In the expression: snocTraversal When checking the transformation rule "snocTraversal" | 23 | {-# RULES "snocTraversal" snoc = snocTraversal #-} | ^^^^^^^^^^^^^ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14322> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2