June 2015 - ghc-tickets

[GHC] #10226: Regression in constraint solver from 7.8 to 7.10
by GHC 13 Jul '15

13 Jul '15

#10226: Regression in constraint solver from 7.8 to 7.10 -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 (Type checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Best explained by example: {{{#!hs {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE AllowAmbiguousTypes #-} -- only necessary in 7.10 {-# LANGUAGE FlexibleContexts #-} -- necessary for showFromF' example type family F a type family FInv a -- This definition is accepted in 7.8 without anything extra, but requires -- AllowAmbiguousTypes in 7.10 (this, by itself, is not a problem): showFromF :: (Show a, FInv (F a) ~ a) => F a -> String showFromF fa = undefined -- Consider what happens when we attempt to call `showFromF` at some type b. -- In order to check that this is valid, we have to find an a such that -- -- > b ~ F a /\ Show a /\ FInv (F a) ~ a -- -- Introducing an intermeidate variable `x` for the result of `F a` gives us -- -- > b ~ F a /\ Show a /\ FInv x ~ a /\ F a ~ x -- -- Simplifying -- -- > b ~ x /\ Show a /\ FInv x ~ a /\ F a ~ x -- -- Set x := b -- -- > Show a /\ FInv b ~ a /\ F a ~ b -- -- Set a := FInv b -- -- > Show (FInv b) /\ FInv b ~ FInv b /\ F (FInv b) ~ b -- -- Simplifying -- -- > Show (FInv b) /\ F (FInv b) ~ b -- -- Indeed, we can give this definition in 7.8, but not in 7.10: showFromF' :: (Show (FInv b), F (FInv b) ~ b) => b -> String showFromF' = showFromF {------------------------------------------------------------------------------- In 7.10 the definition of showFromF' is not accepted, but it gets stranger. In 7.10 we cannot _call_ showFromF at all all, even at a concrete type. Below we try to call it at type b ~ Int. It would need to show > Show (FInv Int) /\ F (FInt Int) ~ Int all of which should easily get resolved, but somehow don't. -------------------------------------------------------------------------------} type instance F Int = Int type instance FInv Int = Int test :: String test = showFromF (0 :: Int) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10226> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10009: type inference regression when faking injective type families
by GHC 13 Jul '15

13 Jul '15

#10009: type inference regression when faking injective type families -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- ghc-7.10.0.20141222 does not accept the program unless I uncomment the type signature (a :: a). ghc-7.8 accepts it as-is. {{{#!hs {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} class (UnF (F a) ~ a, Show a) => C a where type F a f :: F a -> a type family UnF a g :: forall a. C a => a -> String g _ = show a where a = f (undefined :: F a) -- :: a }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10009> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 41

[GHC] #10463: Wrong warning with PartialTypeSignatures
by GHC 13 Jul '15

13 Jul '15

#10463: Wrong warning with PartialTypeSignatures -------------------------------------+------------------------------------- Reporter: augustss | 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: | -------------------------------------+------------------------------------- This program {{{#!hs {-# LANGUAGE ScopedTypeVariables, PartialTypeSignatures #-} f (x :: _) = x ++ "" }}} gives this warning {{{ Bug.hs:2:9: Warning: Found hole ‘_’ with type: [Char] Relevant bindings include f :: [Char] -> [Char] (bound at Bug.hs:2:1) In a pattern type signature: _ In the pattern: x :: _ In an equation for ‘f’: f (x :: _) = x ++ "" }}} But there is no hole, only an _ in a type. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10463> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8709: `make 1` does not work (well)
by GHC 11 Jul '15

11 Jul '15

#8709: `make 1` does not work (well) ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Say I do a `sync-all pull` and then fix a bunch of merge errors. The changes mean that I need to recompile the stage-1 compiler. So, I dutifully `make distclean` and start rebuilding. I then find a bunch of compiler errors in my edited code. Now, I'd like to start the fix error/recompile loop. BUT, when I do `make 1` in the `compiler/` directory, I get errors: {{{ rae:13:49:29 ~/Documents/ghc/compiler> make 1 make -C .. stage=1 all_ghc_stage1 compiler_dist_NO_BUILD_DEPS=YES compiler_dist-boot_NO_BUILD_DEPS=YES compiler_dist- install_NO_BUILD_DEPS=YES NO_GENERATED_MAKEFILE_RULES=YES OMIT_PHASE_0=YES OMIT_PHASE_1=YES compiler_stage1_NO_BUILD_DEPS=YES compiler_stage2_NO_BUILD_DEPS=YES compiler_stage3_NO_BUILD_DEPS=YES ghc_stage1_NO_BUILD_DEPS=YES ghc_stage2_NO_BUILD_DEPS=YES ghc_stage3_NO_BUILD_DEPS=YES ONLY_DEPS_FOR="compiler_stage1 ghc_stage1" ===--- building final phase make -r --no-print-directory -f ghc.mk phase=final all_ghc_stage1 libraries/old-time/ghc.mk:5: libraries/old-time/dist-install/package- data.mk: No such file or directory libraries/haskell98/ghc.mk:5: libraries/haskell98/dist-install/package- data.mk: No such file or directory libraries/haskell2010/ghc.mk:5: libraries/haskell2010/dist-install /package-data.mk: No such file or directory libraries/random/ghc.mk:5: libraries/random/dist-install/package-data.mk: No such file or directory libraries/primitive/ghc.mk:5: libraries/primitive/dist-install/package- data.mk: No such file or directory libraries/vector/ghc.mk:5: libraries/vector/dist-install/package-data.mk: No such file or directory libraries/dph/dph-base/ghc.mk:5: libraries/dph/dph-base/dist-install /package-data.mk: No such file or directory libraries/dph/dph-prim-interface/ghc.mk:5: libraries/dph/dph-prim- interface/dist-install/package-data.mk: No such file or directory libraries/dph/dph-prim-seq/ghc.mk:5: libraries/dph/dph-prim-seq/dist- install/package-data.mk: No such file or directory libraries/dph/dph-prim-par/ghc.mk:5: libraries/dph/dph-prim-par/dist- install/package-data.mk: No such file or directory libraries/dph/dph-lifted-base/ghc.mk:5: libraries/dph/dph-lifted-base /dist-install/package-data.mk: No such file or directory libraries/dph/dph-lifted-boxed/ghc.mk:5: libraries/dph/dph-lifted-boxed /dist-install/package-data.mk: No such file or directory libraries/dph/dph-lifted-copy/ghc.mk:5: libraries/dph/dph-lifted-copy /dist-install/package-data.mk: No such file or directory libraries/dph/dph-lifted-vseg/ghc.mk:5: libraries/dph/dph-lifted-vseg /dist-install/package-data.mk: No such file or directory libraries/ghc-prim/ghc.mk:4: libraries/ghc-prim/dist-install/package- data.mk: No such file or directory libraries/integer-gmp/ghc.mk:4: libraries/integer-gmp/dist-install /package-data.mk: No such file or directory libraries/base/ghc.mk:4: libraries/base/dist-install/package-data.mk: No such file or directory libraries/filepath/ghc.mk:4: libraries/filepath/dist-install/package- data.mk: No such file or directory libraries/array/ghc.mk:4: libraries/array/dist-install/package-data.mk: No such file or directory libraries/deepseq/ghc.mk:4: libraries/deepseq/dist-install/package- data.mk: No such file or directory libraries/bytestring/ghc.mk:4: libraries/bytestring/dist-install/package- data.mk: No such file or directory libraries/containers/ghc.mk:4: libraries/containers/dist-install/package- data.mk: No such file or directory libraries/old-locale/ghc.mk:4: libraries/old-locale/dist-install/package- data.mk: No such file or directory libraries/time/ghc.mk:4: libraries/time/dist-install/package-data.mk: No such file or directory libraries/unix/ghc.mk:4: libraries/unix/dist-install/package-data.mk: No such file or directory libraries/directory/ghc.mk:4: libraries/directory/dist-install/package- data.mk: No such file or directory libraries/process/ghc.mk:4: libraries/process/dist-install/package- data.mk: No such file or directory libraries/hpc/ghc.mk:4: libraries/hpc/dist-install/package-data.mk: No such file or directory libraries/pretty/ghc.mk:4: libraries/pretty/dist-install/package-data.mk: No such file or directory libraries/template-haskell/ghc.mk:4: libraries/template-haskell/dist- install/package-data.mk: No such file or directory libraries/Cabal/Cabal/ghc.mk:4: libraries/Cabal/Cabal/dist-install /package-data.mk: No such file or directory libraries/binary/ghc.mk:4: libraries/binary/dist-install/package-data.mk: No such file or directory libraries/bin-package-db/ghc.mk:4: libraries/bin-package-db/dist-install /package-data.mk: No such file or directory libraries/hoopl/ghc.mk:4: libraries/hoopl/dist-install/package-data.mk: No such file or directory libraries/transformers/ghc.mk:4: libraries/transformers/dist-install /package-data.mk: No such file or directory libraries/xhtml/ghc.mk:4: libraries/xhtml/dist-install/package-data.mk: No such file or directory libraries/terminfo/ghc.mk:4: libraries/terminfo/dist-install/package- data.mk: No such file or directory libraries/haskeline/ghc.mk:4: libraries/haskeline/dist-install/package- data.mk: No such file or directory libraries/integer-gmp/gmp/ghc.mk:49: libraries/integer-gmp/gmp/config.mk: No such file or directory utils/hsc2hs/ghc.mk:16: utils/hsc2hs/dist-install/package-data.mk: No such file or directory utils/ghc-pkg/ghc.mk:66: utils/ghc-pkg/dist-install/package-data.mk: No such file or directory utils/dll-split/ghc.mk:18: utils/dll-split/dist-install/package-data.mk: No such file or directory utils/ghc-pwd/ghc.mk:8: utils/ghc-pwd/dist-install/package-data.mk: No such file or directory utils/ghc-cabal/ghc.mk:67: utils/ghc-cabal/dist-install/package-data.mk: No such file or directory utils/hpc/ghc.mk:18: utils/hpc/dist-install/package-data.mk: No such file or directory utils/runghc/ghc.mk:28: utils/runghc/dist-install/package-data.mk: No such file or directory utils/mkUserGuidePart/ghc.mk:18: utils/mkUserGuidePart/dist/package- data.mk: No such file or directory utils/compare_sizes/ghc.mk:8: utils/compare_sizes/dist-install/package- data.mk: No such file or directory make[2]: *** No rule to make target `libraries/integer-gmp/gmp/config.mk'. Stop. make[1]: *** [all_ghc_stage1] Error 2 make: *** [1] Error 2 }}} Using `make stage=1` works fine, but computing the dependencies each time is annoying. In past experience, I've seen that, once the stage-1 compiler builds to completion at least once, `make 1` works just fine -- it just fails after a `clean`. I don't recall having this problem with `make 2`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8709> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10298: Infinite loop when shared libraries are unavailable
by GHC 10 Jul '15

10 Jul '15

#10298: Infinite loop when shared libraries are unavailable -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.10.1 System | Operating System: Linux Keywords: | Type of failure: Runtime crash Architecture: x86_64 | Blocked By: (amd64) | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Originally discussed at: https://groups.google.com/d/msg/haskell- cafe/5ZTv5mCG_HI/hBJ-VkdpxdoJ. Note that this was originally discussed as a static linking and Docker issue, but in fact affects dynamically linked executables without any containerization. I've put together the following script that reproduces my problem: {{{ cat > hello.hs <<EOF main :: IO () main = putStrLn "Hello World" EOF ghc hello.hs rm -rf tmp mkdir tmp cp hello tmp mkdir -p tmp/usr/lib/x86_64-linux-gnu cp /usr/lib/x86_64-linux-gnu/libgmp.so.10 tmp/usr/lib/x86_64-linux-gnu mkdir -p tmp/lib/x86_64-linux-gnu cp \ /lib/x86_64-linux-gnu/libm.so.6 \ /lib/x86_64-linux-gnu/librt.so.1 \ /lib/x86_64-linux-gnu/libdl.so.2 \ /lib/x86_64-linux-gnu/libc.so.6 \ /lib/x86_64-linux-gnu/libpthread.so.0 \ tmp/lib/x86_64-linux-gnu mkdir -p tmp/lib64 cp /lib64/ld-linux-x86-64.so.2 tmp/lib64 #mkdir -p tmp/usr/lib/x86_64-linux-gnu/gconv/ #cp \ # /usr/lib/x86_64-linux-gnu/gconv/UTF-32.so \ # /usr/lib/x86_64-linux-gnu/gconv/gconv-modules \ # tmp/usr/lib/x86_64-linux-gnu/gconv sudo chroot tmp /hello }}} If I uncomment the block that copies the gconv files, the program runs as expected. However, without those files copied, the program burns CPU and consumes memory until killed by the OS. I ran strace on a similar executable, and got the results at: https://gist.github.com/snoyberg/095efb17e36acc1d6360 Note that this problem also occurs with statically linked executables when some of the other dynamically linked libraries are not available in the chroot environment. Expected behavior: ideal would be not to require the gconv files and other shared libraries be present, especially when statically linked. Barring that, it would be much better if the RTS could produce a meaningful error message about the missing file. Note that strace does demonstrate that a open system call is failing, e.g.: open("/usr/lib/x86_64-linux-gnu/gconv/gconv-modules.cache", O_RDONLY) = -1 ENOENT (No such file or directory) Reproduced on GHC 7.8.4 and 7.10.1, on Ubuntu 14.04 64-bit. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10298> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #10351: Inferred type is rejected
by GHC 09 Jul '15

09 Jul '15

#10351: Inferred type is rejected -------------------------------------+------------------------------------- Reporter: simonpj | 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: | -------------------------------------+------------------------------------- Consider {{{ class C a where op :: a -> () f x = op [x] }}} we get {{{ Foo.hs:14:1: error: Non type-variable argument in the constraint: C [t] (Use FlexibleContexts to permit this) When checking that ‘f’ has the inferred type f :: forall t. C [t] => t -> () }}} Arguably, if `FlexibleContexts` is not on, we should not infer a type that will immediately be rejected. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10351> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10585: Implement proper bidirectional type inference
by GHC 08 Jul '15

08 Jul '15

#10585: Implement proper bidirectional type inference -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 (Type checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The [http://research.microsoft.com/en-us/um/people/simonpj/papers/higher- rank/putting.pdf Practical Type Inference paper] (JFP '07) lays out a nice, relatively straightforward bidirectional type inference algorithm for GHC. The problem is that there is not great hygiene practiced around transitions between "down" checking and "up" checking, neither in the paper nor in the implementation. Examine Figure 8 of the paper, which presents the bidirectional typing rules. There are several syntactic forms which are fundamentally "up" forms -- forms that cannot gain any benefit from any type information being propagated downwards. Examples include App, Var, and Annot. Other forms propagate the very direction they are operated in, such as Let. And then some forms depend somewhat delicately on direction, such as the Abs rules. I propose changing these rules to be more in the style of Figure 4 from Dunfield & Krishnaswami's ICFP'13 paper [http://arxiv.org/pdf/1306.6032v1 here]. The particular rule I'm interested in is DeclSub, paraphrased here: {{{ G |-up e : s1 s1 <= s2 --------------- G |-down e : s2 }}} (I'm not advocating other aspects of their approach, just the general idea around this rule being the only transition between down and up.) In GHC, mediating between "down" checking and "up" checking is done in an ad-hoc manner, made even more difficult by the fact that it takes two separate steps to pull off properly: we must first `deeplyInstantiate` the "up" type that we get and then call `tcSubType` (or one of its variants). And, because this has to be done for each "up" expression form (forms that cannot use down-propagated type information), it's easy to miss a case. As a case in point, consider the following code: {{{ foo :: forall b. b -> (Int -> Int) -> b foo = undefined bar :: ((forall a. a -> a) -> Int) -> Int bar = undefined baz = bar (foo 3) bum = bar (3 `foo`) }}} In 7.10.1, `baz` is accepted, while `bum` is not. This is because the code for left-sections doesn't ever call `tcSubType` -- it uses `unifyType`. While that one case is easy enough to fix, I advocate a redesign of `tcExpr` to break it into two functions: one for "down" forms and one for "up" forms. These would, of course, be mutually recursive in order so that both can handle all expression forms. But these transitions could then be policed more easily. I don't actually think this would entail all that much work, and it would structurally remove the possibility of bugs such as the one above. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10585> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9665: Add "since" information to LANGUAGE extensions in GHC user guide
by GHC 07 Jul '15

07 Jul '15

#9665: Add "since" information to LANGUAGE extensions in GHC user guide -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: Type: task | Status: new Priority: high | Milestone: Component: Documentation | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- If one wants to support older versions of GHC, it is hard to find out whether one can use a certain LANGUAGE extension. One has to go to older versions of the GHC manual to find out whether the corresponding documentation was already there, or browse release notes. Requests: 1. Document for new LANGUAGE extensions that they are available since version 7.10. For example, by adding "(Since GHC 7.10)" to the heading of the new feature. 2. Do this also for the previous LANGUAGE extensions, by adding e.g., "(Since GHC 7.6)" etc. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9665> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #10557: Use `+RTS -G1` for more stable residency measurements
by GHC 07 Jul '15

07 Jul '15

#10557: Use `+RTS -G1` for more stable residency measurements -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Test Suite | 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: | -------------------------------------+------------------------------------- Tests that measure `peak_megabytes_allocated` and `max_bytes_used` can be very sensitive to small changes in, well, just about anything: order of command line flags, what should be irrelevant compiler patches, minor changes in the test file to compile. From `Note [residency]` in `testsuite/tests/perf/compiler/all.T`: {{{ # Residency (peak_megabytes_allocated and max_bytes_used) is sensitive # to when the major GC runs, which makes it inherently inaccurate. # Sometime an innocuous change somewhere can shift things around such # that the samples occur at a different time, and the residency # appears to change (up or down) when the underlying profile hasn't # really changed. }}} I propose setting `+RTS -G1` for these tests. This seems to make them more robust to small changes, as can be seen in the following two graphs, adapted from the test for #9675: https://ghc.haskell.org/trac/ghc/attachment/ticket/9675/T9675-peak_megabyte… https://ghc.haskell.org/trac/ghc/attachment/ticket/9675/T9675-max_bytes_use… This shows the `peak_megabytes_allocated` and `max_bytes_used` as a function of the number fields when compiling a single record: {{{ data Foo = Foo { field1 :: Int -> Int , field2 :: Int -> Int ... }}} The default `GHC -O` line is wiggling up and down, while the `GHC -O +RTS -G1` line is nice and smooth, which is what we want. I don't know if making this change defeats the purpose of some tests, which is why I'm opening this ticket. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10557> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10023: Relax Monad constraint in traceM and traceShowM to Applicative
by GHC 07 Jul '15

07 Jul '15

#10023: Relax Monad constraint in traceM and traceShowM to Applicative -------------------------------------+------------------------------------- Reporter: | Owner: RyanGlScott | Status: new Type: feature | Milestone: request | Version: 7.10.1-rc1 Priority: normal | Operating System: Unknown/Multiple Component: | Type of failure: Other libraries/base | Blocked By: Keywords: | Related Tickets: Architecture: | Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Now that {{{Applicative}}} is a superclass of {{{Monad}}} in GHC 7.10, the current type signatures of {{{traceM}}} and {{{traceShowM}}} from {{{Debug.Trace}}} are too constricted: {{{#!hs traceM :: Monad m => String -> m () traceM string = trace string $ return () traceShowM :: (Show a, Monad m) => a -> m () traceShowM = traceM . show }}} These can be equivalently defined with {{{Applicative}}}: {{{#!hs traceM :: Applicative m => String -> m () traceM string = trace string $ pure () traceShowM :: (Show a, Applicative m) => a -> m () traceShowM = traceM . show }}} However, the {{{M}}} suffixes probably won't make sense after changing the type signatures, so it might be wise to create new {{{traceA}}} and {{{traceShowA}}} functions and deprecate {{{traceM}}} and {{{traceShowM}}}. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10023> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9