May 2016 - ghc-tickets

[GHC] #8774: Transitivity of Auto-Specialization
by GHC 28 Sep '16

28 Sep '16

#8774: Transitivity of Auto-Specialization -------------------------+------------------------------------------------- Reporter: | Owner: crockeea | Status: new Type: bug | Milestone: Priority: | Version: 7.6.3 normal | Operating System: Linux Component: | Type of failure: Compile-time performance bug Compiler | Test Case: Keywords: | Blocking: Architecture: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: 5928, | 8668, 8099 | -------------------------+------------------------------------------------- From [http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/pragmas.html#idp4986… the docs]: [Y]ou often don't even need the SPECIALIZE pragma in the first place. When compiling a module M, GHC's optimiser (with -O) automatically considers each top-level overloaded function declared in M, and specialises it for the different types at which it is called in M. The optimiser also considers each imported INLINABLE overloaded function, and specialises it for the different types at which it is called in M. ... Moreover, given a SPECIALIZE pragma for a function f, GHC will automatically create specialisations for any type-class-overloaded functions called by f, if they are in the same module as the SPECIALIZE pragma, or if they are INLINABLE; and so on, transitively. So GHC should automatically specialize some/most/all(?) functions marked `INLINABLE` ''without'' a pragma, and if I use an explicit pragma, the specialization is transitive. My question is: is the ''auto''-specialization transitive? Either way, I'd like to see the docs updated to answer this question. Specifically, the attached files demonstrate a bug if auto-specialization ''should'' be transitive. Main.hs: {{{ #!haskell import Data.Vector.Unboxed as U import Foo main = let y = Bar $ Qux $ U.replicate 11221184 0 :: Foo (Qux Int) (Bar (Qux ans)) = iterate (plus y) y !! 100 in putStr $ show $ foldl1' (*) ans }}} Foo.hs: {{{ #!haskell module Foo (Qux(..), Foo(..), plus) where import Data.Vector.Unboxed as U newtype Qux r = Qux (Vector r) -- GHC inlines `plus` if I remove the bangs or the Baz constructor data Foo t = Bar !t | Baz !t instance (Num r, Unbox r) => Num (Qux r) where {-# INLINABLE (+) #-} (Qux x) + (Qux y) = Qux $ U.zipWith (+) x y {-# INLINABLE plus #-} plus :: (Num t) => (Foo t) -> (Foo t) -> (Foo t) plus (Bar v1) (Bar v2) = Bar $ v1 + v2 }}} GHC specializes the call to `plus`, but does *not* specialize `(+)` in the `Qux` `Num` instance. (In the attached core excerpt: `main6` calls `iterate main8`. `main8` is just `plus`, specialized for `Int`. So far so good. However, `splus` calls the *polymorphic* `c+`. If auto- specialization is transitive, I expect `c+` to be specialized to `Int`.) This kills performance: an explicit pragma `{-# SPECIALIZE plus :: Foo (Qux Int) -> Foo (Qux Int) -> Foo (Qux Int) #-}` results in ''transitive'' specialization as the docs indicate, so `(+)` is specialized and the code is 30x faster. Is this expected behavior? Should I only expect `(+)` to be specialized transitively with an explicit pragma? Note: this question is different from #5928 for two reasons: 1. I believe that no inlining is occuring, and hence I don't think inlining is interfering with specialization 2. I have `INLINABLE` pragmas on all relevant functions. Note: this question is different from #8668 because I am asking about ''auto''-specialization. This question was originally posted on [http://stackoverflow.com/questions/21502335/transitivity-of-auto- specialization-in-ghc StackOverflow]. As mentioned in the comments of that question, I am intentionally ''not'' fully applying the call to `plus` in Main, contrary to the suggestions in #8099. I'd love to see why I'm getting that behavior as well. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8774> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #11461: Allow pattern synonyms to be bundled with type classes?
by GHC 26 Sep '16

26 Sep '16

#11461: Allow pattern synonyms to be bundled with type classes? -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- One can very nearly get associated pattern synonyms by defining suitably polymorphic pattern synonyms. However, they are not quite associated as there's no way to bundle them with the class. This isn't as good as "proper" support but it would be an easy thing to implement for now if people think it worthwhile. For a concrete example, `Null` is an associated pattern synonym in this style but the following program doesn't compile because it is disallowed to bundle a pattern synonym with a type class. {{{ {-# LANGUAGE PatternSynonyms #-} module Foo(Nullable(Null)) where import Data.Maybe class Nullable f where null :: f a -> Bool instance Nullable (Maybe a) where null = isNothing pattern Null :: Nullable f => f a pattern Null = (null -> True) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11461> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11978: running a profiled build of shake test suite with rts args +RTS -hb -N10 triggers SIGSEV
by GHC 24 Sep '16

24 Sep '16

#11978: running a profiled build of shake test suite with rts args +RTS -hb -N10 triggers SIGSEV ----------------------------------------+--------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 4820 Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- on my 4 core macbook pro i can reliably get a sigsev when running the shake test suite with profiling enabled and the RTS flags +RTS -hb -N10 steps to reproduce (with either ghc 7.10.3 or an 8.0 RC4 build) {{{ cabal get --source shake cd shake # shake master was commit f0c0ce8d4c2c017b9a26b5d4258e07d881f4cde1 as of time of testing # but problem should happen with eg 0.15.6 too cabal install # this is so that the shake test suite can fine the right template file cabal install --only-dep --enable-tests --enable-profiling ./dist/build/shake-test/shake-test +RTS -hb -N10 }}} this last command yields the error {{{ ****************************************************************** ** Running shake test suite, run with '--help' to see arguments ** ****************************************************************** fish: './dist/build/shake-test/shake-t…' terminated by signal SIGSEGV (Address boundary error) }}} i can also trigger the bug reported in #4820 by running the test suite with the -hr flag rather than -hb I'm marking this as HIGHEST so it can be discussed, because the profiiling build of the shake test suite only seems to crash *if* the test suite is run with -hb or -hr flags, which seems like a pretty nasty bug (which colleagues have it in other code) nb: `./dist/build/shake-test/shake-test +RTS -N10 ` runs into a not enough stack space error before the shake test suite completes, but `./dist/build/shake-test/shake-test +RTS -K1G -N10 ` seems to work fine, though the crashes happen super early in the gargantuan test suite the analogous output for reproducing #4820 is : {{{ ./dist/build/shake-test/shake-test +RTS -hr -N10 ****************************************************************** ** Running shake test suite, run with '--help' to see arguments ** ****************************************************************** Longest file modification time lag was 1005ms ## BUILD tar test ## TESTING tar ## BUILD tar --abbrev=output=$OUT -j3 Writing report to $OUT/tar/report.html Build completed in 0:01m ## BUILD tar --no-build --report=- Warning: No want/action statements, nothing to do Writing report to output/tar/report.html Writing report to - * This database has tracked 1 runs. * There are 4 rules (4 rebuilt in the last run). * Building required 1 traced commands (1 in the last run). * The total (unparallelised) time is 0.01s of which 0.01s is traced commands. * The longest rule takes 0.01s (output/tar/result.tar), and the longest traced command takes 0.01s (tar). * Last run gave an average parallelism of 0.44 times over 0.01s. Build completed in 0:01m ## BUILD tar Writing report to output/tar/report.html Build completed in 0:01m ## FINISHED TESTING tar ## BUILD self test ## TESTING self ## BUILD self --abbrev=output=$OUT -j3 Writing report to $OUT/self/report.html Build completed in 0:01m ## BUILD self --no-build --report=- Warning: No want/action statements, nothing to do Writing report to output/self/report.html Writing report to - * This database has tracked 2 runs. * There are 460 rules (2 rebuilt in the last run). * Building required 56 traced commands (1 in the last run). * The total (unparallelised) time is 22.73s of which 22.33s is traced commands. * The longest rule takes 1.11s (output/self/Development/Shake/Types.o output/self/Development/Shake/Types.hi), and the longest traced command takes 1.11s (ghc). * Last run gave an average parallelism of 0.78 times over 0.05s. Build completed in 0:01m ## BUILD self shake-test: internal error: Invalid object in isRetainer(): 39 (GHC version 8.0.0.20160421 for x86_64_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11978> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 33

[GHC] #8523: blowup in space/time for type checking and object size for high arity tuples
by GHC 24 Sep '16

24 Sep '16

#8523: blowup in space/time for type checking and object size for high arity tuples -------------------------+------------------------------------------------- Reporter: | Owner: carter | Status: new Type: bug | Milestone: Priority: | Version: 7.6.3 normal | Operating System: Unknown/Multiple Component: | Type of failure: Compile-time performance bug Compiler | Test Case: Keywords: | Blocking: Architecture: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- Eric Mertens found a compilation performance issue in how GHC handles type class instance methods with many equality constraints and large arity tuples. basically using equality constraints to force 62 variables equal, instead of using the same variable for all the tuple slots, make the type checking time go from 0.9 seconds and very little memory to ~20 seconds and ~ 700mb of ram, along with going from ~ 7,000 coercions to 700,000-400,000 coercions, and object file size of 143kb to an object file size of 2.8mb-3.1mb I'm attaching 2 variants Tuple.hs and NeighborTuple.hs that exhibit the blowup behavior, and MonoTuple.hs (better named PolyTuple.hs but thats a side detail) that doesn't exhibit the blow up behavior. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8523> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11505: Boot file problem
by GHC 22 Sep '16

22 Sep '16

#11505: Boot file problem -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 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: -------------------------------------+------------------------------------- Here are two modules and a boot file. Compile by {{{ ghc -c Foo.hs-boot; ghc -c Bar.hs; ghc -c Foo.hs }}} and observe this error message {{{ Foo.hs:12:1: Type constructor `Foo' has conflicting definitions in the module and its hs-boot file Main module: data Foo = Foo {x :: {-# UNPACK #-} !Int} Boot file: data Foo = Foo {x :: !Int} }}} But the definitions are not conflicting, they are identical. Foo.hs-boot: {{{ module Foo where data Foo = Foo { x :: {-# UNPACK #-} !Int } }}} Foo.hs: {{{ module Foo where import Bar data Foo = Foo { x :: {-# UNPACK #-} !Int } }}} Bar.hs: {{{ module Bar where import {-# SOURCE #-} Foo }}} Removing the unbox pragma gives the even more perplexing: {{{ Foo.hs:3:1: Type constructor `Foo' has conflicting definitions in the module and its hs-boot file Main module: data Foo = Foo {x :: !Int} Boot file: data Foo = Foo {x :: !Int} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11505> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9421: magic number mismatch when installing 32bit on 64bit machine
by GHC 18 Sep '16

18 Sep '16

#9421: magic number mismatch when installing 32bit on 64bit machine -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Installing Difficulty: Unknown | GHC failed Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- This is basically the same problem as reported here: https://www.mail-archive.com/ghc-devs@haskell.org/msg04439.html I have empty .cabal and .ghc, no ghc in paths and I have old Ubuntu LTS (12.04.4) so I was able to install ia32-libs and a few other libs I've downloaded http://www.haskell.org/ghc/dist/7.8.3/ghc-7.8.3-i386-unknown-linux- deb7.tar.xz configured, and make install says: {{{ Installing library in /mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3/haskell98-2.0.0.3 "utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" copy libraries/haskell2010 dist-install "strip" '' '/mikolaj/env/7.8.3i386/local/src/ghc' '/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3' '/mikolaj/env/7.8.3i386/local/src/ghc/share/doc/ghc/html/libraries' 'v p dyn' Installing library in /mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3/haskell2010-1.1.2.0 "/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3/bin/ghc-pkg" --force --global-package-db "/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3/package.conf.d" update rts/dist/package.conf.install Reading package info from "rts/dist/package.conf.install" ... done. "utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" register libraries/ghc-prim dist-install "/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3/bin/ghc" "/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3/bin/ghc-pkg" "/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3" '' '/mikolaj/env/7.8.3i386/local/src/ghc' '/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3' '/mikolaj/env/7.8.3i386/local/src/ghc/share/doc/ghc/html/libraries' NO ghc-cabal: Bad interface file: dist-install/build/GHC/CString.hi magic number mismatch: old/corrupt interface file? (wanted 33214052, got 129742) make[1]: *** [install_packages] Error 1 make: *** [install] Error 2 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9421> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #10167: Error with dash character
by GHC 17 Sep '16

17 Sep '16

#10167: Error with dash character -------------------------------------+------------------------------------- Reporter: elvinz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Windows Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When I copy the formula from the webpage http://www.experiglot.com/2006/06/07/how-to-convert-from-an-annual-rate- to-an-effective-periodic-rate-javascript-calculator/ as this formula: yearlyToMonthly rate nbPeriods = (1 + rate)(1 / nbPeriods) – 1 I get the following error message in ghci which is due the the minus character not being encoded as an hyphen but as an en dash: main.hs:3:60: Not in scope: `*** Exception: <stderr>: commitBuffer: invalid argu ment (invalid character) Would it be possible to have a more informative error message ? My system is win 7 64 bits, and the locale is fr;French (France). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10167> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11403: Provide a way to make fast in-calls into Haskell
by GHC 16 Sep '16

16 Sep '16

#11403: Provide a way to make fast in-calls into Haskell -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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: -------------------------------------+------------------------------------- Currently, there is no way to call into Haskell without creating a new Haskell thread and running the schedular, which is rather slow. It would be nice to be able to make faster calls into Haskell, even if some state had to be persisted on the C side and passed to the RTS each time. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11403> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10417: Rule matching not "seeing through" floating and type lambda (and maybe cast)
by GHC 15 Sep '16

15 Sep '16

#10417: Rule matching not "seeing through" floating and type lambda (and maybe cast) -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The nub of the problem looks like this. We have a RULE: {{{#!hs {-# RULES "Sequence/Sequence" forall a b c. Sequence (Sequence a b) c = Sequence a (Sequence b c) #-} }}} and some core code that looks like: {{{#!hs failing_example = \ @ s_azo -> Sequence ((failing_example3) `cast` ...) (...) failing_example3 = \ @ s_azo -> Sequence (...) (...) }}} We would hope that the rule would match here but clearly it does not. There's obviously a few things in the way of a straightforward match: 1. the key subterm is floated out 2. there's a `\ @ ->` type lambda in the way in the subterm 3. there's a `cast` in the way in the subterm It appears that the problem is not the cast but the combination of 1 & 2. A reduced example shows the problem occurs with just the first two. That said, the real code would also rely on it working with the `cast`. ---- The rest of this is the code needed to construct the example. The code is also attached to the ticket. {{{#!hs {-# LANGUAGE GADTs, RankNTypes, TypeOperators, ScopedTypeVariables, TypeFamilies, KindSignatures, DataKinds, UndecidableInstances #-} module RulesExample (working_example2) where import Prelude hiding (pure, (<*>)) data Decoder s s' where -- explicit encoding of sequencing Done :: Decoder s s Sequence :: Decoder a b -> Decoder b c -> Decoder a c -- primitive operation in "chained" style ConsumeWord :: Decoder (Word :*: s) s' -> Decoder s s' AlterStack :: (a -> b) -> Decoder b s' -> Decoder a s' data a :*: b = a :*: b infixr 5 :*: }}} We compose actions using the explicit encoding of sequencing {{{#!hs a >>> b = Sequence a b }}} Aside: in the real thing we go via the category class: instance Category Decoder where id = Done a . b = Sequence b a {-# INLINE (.) #-} the Category module defines >>> as flip (.) Now our primitives are in the chained style, and we turn them into the explicit sequencing style by chaining them with Done: {{{#!hs consumeWord :: Decoder s (Word :*: s) consumeWord = ConsumeWord Done alter :: (a -> b) -> Decoder a b alter f = AlterStack f Done }}} example of explicit sequencing: {{{ consumeWord >>> consumeWord >>> ... }}} but naively this will give us things like: {{{ ConsumeWord Done `Sequence` ConsumeWord Done `Sequence` ... }}} and we can interpret this much faster if it's in the "chained" style {{{ ConsumeWord (ConsumeWord (... ) ) }}} Aside: there are good reasons not to just try and construct this chained style in the first place. We can't do it everywhere, and where it would fail we would get bad code. Rather we want to start with something ok and optimise it locally. So, we use RULES to reassociate things and eliminate the Sequence and Done where possible: {{{#!hs {-# RULES "Sequence/Done" forall sa. Sequence Done sa = sa #-} {-# RULES "Sequence/Sequence" forall a b c. Sequence (Sequence a b) c = Sequence a (Sequence b c) #-} {-# RULES "Sequence/ConsumeWord" forall sa sa'. Sequence (ConsumeWord sa) sa' = ConsumeWord (Sequence sa sa') #-} {-# RULES "Sequence/AlterStack" forall f sa sa'. Sequence (AlterStack f sa) sa' = AlterStack f (Sequence sa sa') #-} }}} Now for starters, ghc produces warnings for all three RULES like: {{{ Rule "Sequence/Done" may never fire because ‘RulesExample.Sequence’ might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma on ‘RulesExample.Sequence’ }}} but it's currently syntactically invalid to write such a pragma: {{{ {-# INLINE [0] Done #-} {-# INLINE [0] Sequence #-} }}} and also, the warning isn't wholly correct, the rule can fire: {{{#!hs working_example = consumeWord >>> consumeWord >>> alter (\(a :*: b :*: s) -> (a,b) :*: s) }}} actually, this isn't yet quite enough because we cannot persuade ghc to inline consumeWord, because it's just a static composition of constructors, not even if we hit it with the INLINE pragma: {{{#!hs {-# INLINE consumeWord #-} }}} we have to resort to the bigger hammer of an inline rule: {{{#!hs {-# RULES "inline consumeWord" consumeWord = ConsumeWord Done #-} }}} now this is good, we get exactly the core that we want: {{{ $WDone = \ @ s_anC -> Done @~ <s_anC>_N working_example3 = \ @ b_aw2 ds_dAY -> case ds_dAY of _ { :*: a_aoc ds1_dAZ -> case ds1_dAZ of _ { :*: b1_aod s_aoe -> :*: (a_aoc, b1_aod) s_aoe } } working_example2 = \ @ b_aw2 -> AlterStack (working_example3) ($WDone) working_example1 = \ @ b_aw2 -> ConsumeWord (working_example2) working_example = \ @ b_aw2 -> ConsumeWord (working_example1) }}} This is perfect. Each constructor is statically allocated and refers to the next one in the chain. This allows the interpreter to walk over this without triggering any allocation, and the chain style means that in the usual case it doesn't have to do control flow call/return work for the Sequence/Done. Note already that we may have an issue with rule matching on Done, since it does get changed later into $WDone. So it could actually be useful to be able to write: {{{ {-# INLINE [0] Done #-} }}} Ok, so, what doesn't work... Floating things out is not itself a problem, this still works fine, the rules fire. So apparently the `\ @ b_aw2 -> ` type abstraction isn't a problem for the rule matching. {{{#!hs second_example = consumeWord >>> part2 part2 = consumeWord >>> part3 part3 = alter (\(a :*: b :*: s) -> (a,b) :*: s) }}} However the following fails to work. This example is actually extracted from the core of a real example that doesn't work. {{{#!hs artificial_example = Sequence failing_example3 failing_example1 where failing_example3 = Sequence failing_example5 failing_example4 failing_example5 = Sequence Done failing_example6 failing_example6 = ConsumeWord Done failing_example4 = ConsumeWord Done failing_example1 = AlterStack failing_example2 Done failing_example2 (a :*: b :*: s) = (a,b) :*: s }}} here's a specific example of a rule not matching: {{{ ailing_example3 = \ @ a_ax3 -> Sequence (failing_example4) (failing_example4) failing_example4 = \ @ s_awp -> ConsumeWord ($WDone) }}} This should match the rule {{{ Sequence (ConsumeWord sa) sa' = ConsumeWord (Sequence sa sa') }}} but apparently does not. The combo of the floating out and the type lambda seem to get in the way. Note that in this example ghc has also CSE'd the failing_example4 with failing_example5 and so failing_example4 is used twice. But if that's the problem here, there also equivalent instances of the Sequence/Sequence rule not matching. Also, ConsumeWord is certainly CONLIKE so we'd hope even if ghc had already CSEd that it'd allow the duplication for the rule matching. In fact looking at the simpl iterations I think the rule would have gotten a chance to fire before the CSE occured. In the real example that the above was extracted from we also have `cast`s in the way. Unfortunately we need more infrastructure to illustrate the full example. I don't think the details of this infrastructure is important, except that it ends up giving us `cast` in the core. We're building an abstraction on top of Decoder to let us use Applicative style. {{{#!hs data Fun a = Id | Cons a | O (Fun a) (Fun a) -- this requires UndecidableInstances type family Apply (f :: Fun *) (a :: *) :: * type instance Apply Id a = a type instance Apply (Cons x) a = x :*: a type instance Apply (O f g) a = Apply f (Apply g a) }}} we pair up stack changes and their inverses {{{#!hs data DecoderA0 s (f :: Fun *) a = DecoderA0 (Decoder s (Apply f s)) -- change the stack from s -> f s (Apply f s -> (s, a)) -- change stack back from f s -> s {-# INLINE pure0 #-} pure0 :: forall a s. a -> DecoderA0 s Id a pure0 a = DecoderA0 Done (\s -> (s, a)) {-# INLINE app0 #-} app0 :: DecoderA0 s f (a -> b) -> DecoderA0 (Apply f s) g a -> DecoderA0 s (g `O` f) b app0 (DecoderA0 d f) (DecoderA0 d' x) = DecoderA0 (d >>> d') appStack where -- just flipped <*> for state monad appStack = \s -> case x s of (s', x') -> case f s' of (s'', f') -> (s'', f' x') {-# INLINE close0 #-} close0 :: forall s f a. DecoderA0 s f a -> Decoder s (a :*: s) close0 (DecoderA0 d se) = d >>> alter se' where se' :: Apply f s -> (a :*: s) se' s = case se s of (s', a) -> a :*: s' }}} now we can abstract over the stack change, because it always takes us back to the same initial stack state {{{#!hs data DecoderA a where DecoderA :: (forall s. DecoderA0 s f a) -> DecoderA a }}} in the real thing we use Functor and Applicative instances, but we only need bits {{{#!hs pure a = DecoderA (pure0 a) DecoderA f <*> DecoderA x = DecoderA (app0 f x) infixl 4 <*> }}} now conversions functions: {{{#!hs {-# INLINE embedDecoderA #-} embedDecoderA :: DecoderA a -> Decoder s (a :*: s) embedDecoderA (DecoderA ap) = close0 ap {-# INLINE[1] embedDecoder #-} embedDecoder :: forall a. (forall s. Decoder s (a :*: s)) -> DecoderA a embedDecoder dec = DecoderA popResultAp where popResultAp :: DecoderA0 s (Cons a) a popResultAp = DecoderA0 dec (\(a :*: s) -> (s, a)) }}} ok, we can finally build our example... {{{#!hs failing_example = embedDecoderA $ pure (,) <*> embedDecoder consumeWord <*> embedDecoder consumeWord }}} So all the applicative stuff gets inlined away, but we end up with this core: {{{ $WDone = \ @ s_anC -> Done @~ <s_anC>_N failing_example6 = \ @ s_azo -> ConsumeWord ($WDone) failing_example4 = \ @ s_azo -> ConsumeWord ($WDone) failing_example5 = \ @ s_azo -> Sequence (($WDone) `cast` ...) ((failing_example6) `cast` ...) failing_example3 = \ @ s_azo -> Sequence ((failing_example5) `cast` ...) ((failing_example4) `cast` ...) failing_example2 = \ @ s_azo s1_aox -> case s1_aox `cast` ... of _ { :*: a_aoH s2_aoI -> case s2_aoI `cast` ... of _ { :*: a1_Xpa s3_Xpc -> :*: (a1_Xpa, a_aoH) (s3_Xpc `cast` ...) } } failing_example1 = \ @ s_azo -> AlterStack (failing_example2) ($WDone) failing_example = \ @ s_azo -> Sequence ((failing_example3) `cast` ...) (failing_example1) }}} We have two examples of RULES not mathing where we would have hoped. Firstly, we have: {{{ Sequence (($WDone) `cast` ...) (...) }}} We would of course hope that the rule Sequence Done sa = sa would match here It's unclear if this is due to the `$WDone` or the `cast`. Certainly the conversion from Done to `$WDone` can be worked around by using a function {{{ {-# INLINE [0] done #-} done = Done }}} and changing the code and rules to use that. So the main problem is the one mentioned at the top of the ticket: {{{ failing_example = \ @ s_azo -> Sequence ((failing_example3) `cast` ...) (...) failing_example3 = \ @ s_azo -> Sequence (...) (...) }}} We would hope that this rule would match {{{ Sequence (Sequence a b) c = Sequence a (Sequence b c) }}} So this is the same issue as in the artificial example but now additionally there's a `cast` in the way in the subterm. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10417> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12015: Add conditional CallStack constraints to common partial utility functions
by GHC 15 Sep '16

15 Sep '16

#12015: Add conditional CallStack constraints to common partial utility functions -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 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: -------------------------------------+------------------------------------- There are a variety of common utility functions used throughout GHC which are partial (e.g. many of the helpers in `Type`, for instance, `kindPrimRep`). It would be great if [ImplicitCallStacks] would identify their callers. However, we likely don't want to pay the cost of passing around `CallStacks` during normal compilation so I propose we make them conditional on `DEBUG`. That is, define {{{#!hs #if DEBUG type DebugCallStack = CallStack #else type DebugCallStack = (() :: Constraint) #endif }}} Now we can sprinkle `DebugCallStack` constraints about GHC and get the best of both worlds! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12015> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3