August 2018 - ghc-tickets

[GHC] #15550: Names of RULES aren't quoted in -ddump-splices
by GHC 18 Sep '18

18 Sep '18

#15550: Names of RULES aren't quoted in -ddump-splices -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Template | Version: 8.4.3 Haskell | 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: -------------------------------------+------------------------------------- Compile the following program: {{{#!hs {-# LANGUAGE TemplateHaskell #-} {-# OPTIONS_GHC -ddump-splices #-} module Bug where $([d| myId :: a -> a myId x = x {-# NOINLINE [1] myId #-} {-# RULES "myId" forall x. myId x = x #-} |]) }}} {{{ $ /opt/ghc/8.4.3/bin/ghci Bug.hs GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/ryanglscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:(5,3)-(9,6): Splicing declarations [d| {-# RULES "myId" forall x_a1xu. myId_a1xr x_a1xu = x_a1xu #-} myId_a1xr :: a_a1xs -> a_a1xs myId_a1xr x_a1xt = x_a1xt {-# NOINLINE [1] myId_a1xr #-} |] ======> myId_a49f :: a_a49e -> a_a49e myId_a49f x_a49g = x_a49g {-# NOINLINE [1] myId_a49f #-} {-# RULES myId forall x_a49h. myId_a49f x_a49h = x_a49h #-} Ok, one module loaded. }}} Notice how in the bottom of the `-ddump-splices` output, the name of the rewrite rule for `myId` isn't surrounded by double quotes, thus making it syntactically invalid. That is, it's printed as: {{{#!hs {-# RULES myId forall x_a49h. myId_a49f x_a49h = x_a49h #-} }}} Whereas it should be: {{{#!hs {-# RULES "myId" forall x_a49h. myId_a49f x_a49h = x_a49h #-} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15550> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #15572: TH improperly converts promoted data cons in ConT
by GHC 18 Sep '18

18 Sep '18

#15572: TH improperly converts promoted data cons in ConT -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Template | Version: 8.4.3 Haskell | 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: -------------------------------------+------------------------------------- If you compile the following program: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE TemplateHaskell #-} {-# OPTIONS_GHC -ddump-splices #-} module Bug where import Language.Haskell.TH $([d| type AbsoluteUnit1 = '() |]) $(pure [TySynD (mkName "AbsoluteUnit2") [] (ConT '())]) }}} {{{ $ /opt/ghc/8.6.1/bin/ghci Bug.hs GHCi, version 8.6.0.20180810: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:8:3-33: Splicing declarations [d| type AbsoluteUnit1_a1HN = '() |] ======> type AbsoluteUnit1_a4qs = '() Bug.hs:9:3-54: Splicing declarations pure [TySynD (mkName "AbsoluteUnit2") [] (ConT '())] ======> type AbsoluteUnit2 = () }}} You'll notice an unusual discrepancy between the two `-ddump-splices` logs. In the first one: {{{#!hs type AbsoluteUnit1_a4qs = '() }}} The `'()` constructor is properly preceded with a single quote. In the second one, however: {{{#!hs type AbsoluteUnit2 = () }}} `'()` incorrectly appears without a single quote! The culprit is in the way `Convert` [http://git.haskell.org/ghc.git/blob/154d4e219cc0cebbef8a845609bd63ec45fdbea… handles] `ConT`: {{{#!hs ConT nm -> do { nm' <- tconName nm ; mk_apps (HsTyVar noExt NotPromoted (noLoc nm')) tys'} }}} This code naïvely assumes that `ConT` will never contain a promoted data constructor name by hardcoding `NotPromoted`. We really ought to be checking if `nm'` is a data con `RdrName` here and using `Promoted` if so, and `NotPromoted` otherwise. Patch incoming. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15572> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10859: Generated Eq instance associates && wrongly
by GHC 18 Sep '18

18 Sep '18

#10859: Generated Eq instance associates && wrongly -------------------------------------+------------------------------------- Reporter: nomeata | Owner: simonpj Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #10858 Differential Revisions: | -------------------------------------+------------------------------------- Currently, we derive this code for `(==)`: {{{ (==) (ImportDecl a1_acXi a2_acXj a3_acXk a4_acXl a5_acXm a6_acXn a7_acXo a8_acXp) (ImportDecl b1_acXq b2_acXr b3_acXs b4_acXt b5_acXu b6_acXv b7_acXw b8_acXx) = (((((((((a1_acXi == b1_acXq)) && ((a2_acXj == b2_acXr))) && ((a3_acXk == b3_acXs))) && ((a4_acXl == b4_acXt))) && ((a5_acXm == b5_acXu))) && ((a6_acXn == b6_acXv))) && ((a7_acXo == b7_acXw))) && ((a8_acXp == b8_acXx))) }}} To me this looks wrongly associated: Since `&&` is strict in the left but lazy in the right argument, shouldn’t this be associated the other way around? The compiler might clean it up later, but why not produce it correctly right away? The culprit is this line: {{{ = foldl1 and_Expr (zipWith3Equal "nested_eq" nested_eq tys as bs) }}} and I was just about to change that ot `foldr1`, but then I did some git- archeology and found that Simon changed that deliberately from `foldr1` to `foldl1` in changeset:8de16184643ea3c2f9f30b5eaed18db6ef247760. Simon, do you still recall what you were thinking when you applied this commit ... 18½years ago? :-) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10859> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #15510: Qualified Holes
by GHC 18 Sep '18

18 Sep '18

#15510: Qualified Holes -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature | Status: new request | Priority: low | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- Let us consider the following example code: {{{ import qualified Data.Map as M main :: IO () main = print (M._ (\k v acc -> k + v + acc) 0 myMap) myMap :: Map Int Int myMap = ... }}} This errors with `Not in scope: M._`. It would cool if GHC instead treated `M._` as a hole but only gave suggestions from the module `Data.Map`. So, in this case, it would suggest things like `Data.Map.foldrWithKey` and `Data.Map.foldlWithKey`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15510> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15208: GHC 8.4 fails to build on Debian armel (softfloat)
by GHC 18 Sep '18

18 Sep '18

#15208: GHC 8.4 fails to build on Debian armel (softfloat) --------------------------------+--------------------------------- Reporter: clint | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Linux Architecture: arm | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+--------------------------------- This seems intentional but on the other hand the error message says "Please report this as a GHC bug" {{{ "inplace/bin/ghc-stage1" -static -H32m -O -lffi -optl-pthread -optl-B/usr/bin/ld.gold -Wall -Iincludes -Iincludes/dist -Iincludes /dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -optc-DNOSMP -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical- monad-instances -c rts/StgStartup.cmm -o rts/dist/build/StgStartup.o "inplace/bin/ghc-stage1" -static -H32m -O -lffi -optl-pthread -optl-B/usr/bin/ld.gold -Wall -Iincludes -Iincludes/dist -Iincludes /dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -optc-DNOSMP -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical- monad-instances -c rts/PrimOps.cmm -o rts/dist/build/PrimOps.o "inplace/bin/ghc-stage1" -static -H32m -O -lffi -optl-pthread -optl-B/usr/bin/ld.gold -Wall -Iincludes -Iincludes/dist -Iincludes /dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -optc-DNOSMP -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical- monad-instances -c rts/Updates.cmm -o rts/dist/build/Updates.o ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.4.3 for arm-unknown-linux): Failed to lookup the datalayout for armv7l-unknown-linux-gnueabi; available targets: ["i386-unknown-windows","i686-unknown-windows","x86_64 -unknown-windows","arm-unknown-linux-gnueabihf","armv6-unknown-linux- gnueabihf","armv6l-unknown-linux-gnueabihf","armv7-unknown-linux-gnueabihf ","armv7a-unknown-linux-gnueabi","armv7l-unknown-linux-gnueabihf","aarch64 -unknown-linux-gnu","aarch64-unknown-linux","i386-unknown-linux-gnu","i386 -unknown-linux","x86_64-unknown-linux-gnu","x86_64-unknown-linux","armv7 -unknown-linux-androideabi","aarch64-unknown-linux-android","arm-unknown- nto-qnx-eabi","i386-apple-darwin","x86_64-apple-darwin","armv7-apple- ios","aarch64-apple-ios","i386-apple-ios","x86_64-apple-ios"] CallStack (from HasCallStack): error, called at compiler/llvmGen/LlvmCodeGen.hs:96:24 in ghc:LlvmCodeGen Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug rts/ghc.mk:295: recipe for target 'rts/dist/build/StgStartup.o' failed make[3]: *** [rts/dist/build/StgStartup.o] Error 1 make[3]: *** Waiting for unfinished jobs.... ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.4.3 for arm-unknown-linux): Failed to lookup the datalayout for armv7l-unknown-linux-gnueabi; available targets: ["i386-unknown-windows","i686-unknown-windows","x86_64 -unknown-windows","arm-unknown-linux-gnueabihf","armv6-unknown-linux- gnueabihf","armv6l-unknown-linux-gnueabihf","armv7-unknown-linux-gnueabihf ","armv7a-unknown-linux-gnueabi","armv7l-unknown-linux-gnueabihf","aarch64 -unknown-linux-gnu","aarch64-unknown-linux","i386-unknown-linux-gnu","i386 -unknown-linux","x86_64-unknown-linux-gnu","x86_64-unknown-linux","armv7 -unknown-linux-androideabi","aarch64-unknown-linux-android","arm-unknown- nto-qnx-eabi","i386-apple-darwin","x86_64-apple-darwin","armv7-apple- ios","aarch64-apple-ios","i386-apple-ios","x86_64-apple-ios"] CallStack (from HasCallStack): error, called at compiler/llvmGen/LlvmCodeGen.hs:96:24 in ghc:LlvmCodeGen Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug rts/ghc.mk:295: recipe for target 'rts/dist/build/Updates.o' failed make[3]: *** [rts/dist/build/Updates.o] Error 1 ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.4.3 for arm-unknown-linux): Failed to lookup the datalayout for armv7l-unknown-linux-gnueabi; available targets: ["i386-unknown-windows","i686-unknown-windows","x86_64 -unknown-windows","arm-unknown-linux-gnueabihf","armv6-unknown-linux- gnueabihf","armv6l-unknown-linux-gnueabihf","armv7-unknown-linux-gnueabihf ","armv7a-unknown-linux-gnueabi","armv7l-unknown-linux-gnueabihf","aarch64 -unknown-linux-gnu","aarch64-unknown-linux","i386-unknown-linux-gnu","i386 -unknown-linux","x86_64-unknown-linux-gnu","x86_64-unknown-linux","armv7 -unknown-linux-androideabi","aarch64-unknown-linux-android","arm-unknown- nto-qnx-eabi","i386-apple-darwin","x86_64-apple-darwin","armv7-apple- ios","aarch64-apple-ios","i386-apple-ios","x86_64-apple-ios"] CallStack (from HasCallStack): error, called at compiler/llvmGen/LlvmCodeGen.hs:96:24 in ghc:LlvmCodeGen Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug rts/ghc.mk:295: recipe for target 'rts/dist/build/PrimOps.o' failed }}} https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=armel&ver=8.4.3-1&s… -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15208> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #13617: Segfault in Windows GHCi involving C code compiled with -O4
by GHC 17 Sep '18

17 Sep '18

#13617: Segfault in Windows GHCi involving C code compiled with -O4 ----------------------------------------+------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+------------------------------- This is a very elusive bug that I noticed when running an `hmatrix` example under GHCi on Windows. Luckily, this example can be reduced down to a couple of `.hs` files and a single `.c` file (with no other Haskell or C dependencies). Unfortunately, I can't quite figure out a way to reproduce this bug without `cabal`, so I've put the source code at https://github.com/RyanGlScott/hmatrix-segfault. You can reproduce this bug by doing the following: {{{ $ git clone https://github.com/RyanGlScott/hmatrix-segfault $ git reset 2bfe38f964fca64dd776993c89ec59d35fb368a5 $ cd hmatrix-segfault/ $ cabal install $ runghc exe/Main.hs Access violation in generated code when reading ffffffffffffffff }}} Running `Main.hs` in GHCi crashes, whereas compiling it works: {{{ $ ghc exe/Main.hs $ ./exe/Main.exe [1,1,1,1,1,1,1,1,1,1,1,1] }}} I've reproduced this with GHC 7.10.3, 8.0.2, and 8.2.1-rc1. There are a couple of things that appear to be necessary to trigger the segfault: 1. You need to have `-O4` under `cc-options` in `hmatrix-segfault.cabal`. 2. You need to define the [https://github.com/RyanGlScott/hmatrix- segfault/blob/2bfe38f964fca64dd776993c89ec59d35fb368a5/src/Internal/Vectorized.hs#L38 FunCodeS] datatype. Removing either of these things causes the program to work again under GHCi. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13617> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #12457: Deriving should be (more closely) integrated with other metaprogramming methods
by GHC 17 Sep '18

17 Sep '18

#12457: Deriving should be (more closely) integrated with other metaprogramming methods -------------------------------------+------------------------------------- Reporter: mpickering | Owner: 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: -------------------------------------+------------------------------------- It is unfortunate that if we want to (efficiently) derive a new type class then we have to bake the derivation logic into GHC itself. It seems desirable to be able to implement new deriving methods in libraries in some manner. Ryan Scott says: > I think this would be a wonderful thing to have. Matthew Pickering > (cc'd) has expressed a desire to have all the logic for the `bespoke` > deriving strategies compartmentalized into a library that could easily > be expanded on in the future to support more typeclasses in base. > (Bifunctor, anyone?) > > Unfortunately, each of the major players in today's Haskell > metaprogramming scene that I'm aware of have some downfalls that make > them unsuitable as `deriving` replacements: > > * Template Haskell: Not portable. Staging issues make it hard to use as a drop-in replacement for the `deriving` keyword > * GHC generics: Can't express all the optimizations that the bespoke `deriving` algorithms perform. Unperformant. > * Haskell preprocessors: Difficult to integrate in a typical GHC workflow. Probably wouldn't have all the metadata you'd need to be feature-complete with what `deriving` does today. > > The way I see it, the whole `deriving` business as it currently stands > today is a somewhat-grotesque-but-darn-useful hack that gets around > the lack of a truly nice metaprogramming facility in Haskell. I'm > holding out hope that the work in > https://github.com/shayan-najd/NativeMetaprogramming makes things > nicer soon, and then we can revisit this idea. Until then, > -XDerivingStrategies provides a way to contain some of the madness of > `deriving` after having many features tacked onto it in recent GHC > releases. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12457> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #13862: Optional "-v" not allowed with :load in GHCi
by GHC 16 Sep '18

16 Sep '18

#13862: Optional "-v" not allowed with :load in GHCi -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 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: -------------------------------------+------------------------------------- When loading a file in GHCi with the command {{{:load}}} and the file must import another file, if that other file is unavailable then GHCi sends the following error\\ {{{ Failed to load interface for `xxx` Use -v to see a list of the files searched for. }}} ' xxx ' is the name of the imported file that GHCi cannot find.\\ But we can not use a flag ( ie -v) with the command {{{:load}}} in GHCi.\\ This error is not appropriate in GHCi when using {{{:load}}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13862> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #14921: Type inference breaks on constraint-kinded parameter used by a Rank-2 callback
by GHC 16 Sep '18

16 Sep '18

#14921: Type inference breaks on constraint-kinded parameter used by a Rank-2 callback -------------------------------------+------------------------------------- Reporter: glittershark | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 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: -------------------------------------+------------------------------------- Apologies in advance if the terminology in the summary is incorrect, I'm not really sure of the proper terms to use here The following code: {{{#!hs {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE ScopedTypeVariables #-} module Scratch where import Prelude data Foo = FooA Int | FooB String useFoo :: forall cls a . (cls Int, cls String) => (forall k . cls k => k -> a) -> Foo -> a useFoo f (FooA a) = f a useFoo f (FooB b) = f b }}} seems like it should be able to infer the `cls` type parameter to `useFoo` based on the first argument, but instead calling with `kshow` gives the following error message: {{{#!hs >>> useFoo show (FooA 1) <interactive>:52:1: error: • Could not deduce: (cls0 Int, cls0 String) arising from a use of ‘useFoo’ • In the expression: useFoo show (FooA 1) In an equation for ‘it’: it = useFoo show (FooA 1) <interactive>:52:8: error: • Couldn't match type ‘a’ with ‘String’ ‘a’ is untouchable inside the constraints: cls0 k bound by a type expected by the context: forall k. cls0 k => k -> a at <interactive>:52:1-20 ‘a’ is a rigid type variable bound by the inferred type of it :: a at <interactive>:52:1-20 Possible fix: add a type signature for ‘it’ Expected type: k -> a Actual type: k -> String • In the first argument of ‘useFoo’, namely ‘show’ In the expression: useFoo show (FooA 1) In an equation for ‘it’: it = useFoo show (FooA 1) • Relevant bindings include it :: a (bound at <interactive>:52:1) }}} Type-applying `useFoo` works as expected: {{{#!hs >>> :set -XTypeApplications >>> useFoo @Show show (FooA 1) "1" }}} This broke both with and without ScopedTypeVariables -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14921> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10651: Type checking issue with existential quantification, rank-n types and constraint kinds
by GHC 16 Sep '18

16 Sep '18

#10651: Type checking issue with existential quantification, rank-n types and constraint kinds -------------------------------------+------------------------------------- Reporter: Roboguy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 (Type checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: | valid program Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I'm trying to create a library for working with lists with existentially quantified types and I ran into an issue implementing `mapM_` for my type (note that the `map` and `mapM` implementations both work fine): {{{#!hs {-# LANGUAGE RankNTypes, ExistentialQuantification, ConstraintKinds #-} data ConstrList c = forall a. c a => a :> ConstrList c | CNil infixr :> constrMap :: (forall a. c a => a -> b) -> ConstrList c -> [b] constrMap f (x :> xs) = f x : constrMap f xs constrMap f CNil = [] constrMapM :: Monad m => (forall a. c a => a -> m b) -> ConstrList c -> m [b] constrMapM f = sequence . constrMap f -- Doesn't work, even with the definition as undefined (?) constrMapM_ :: Monad m => (forall a. c a => a -> m b) -> ConstrList c -> m () constrMapM_ = undefined }}} It fails with this error message: {{{ /users/dyoung/Test.hs:16:16: Couldn't match type ‘b0’ with ‘b’ ‘b0’ is untouchable inside the constraints (c a) bound by the type signature for constrMapM_ :: c a => a -> m b0 at /users/dyoung/Test.hs:16:16-77 ‘b’ is a rigid type variable bound by the type signature for constrMapM_ :: Monad m => (forall a. c a => a -> m b) -> ConstrList c -> m () at /users/dyoung/Test.hs:16:16 Expected type: a -> m b0 Actual type: a -> m b In the ambiguity check for the type signature for ‘constrMapM_’: constrMapM_ :: forall (c :: * -> Constraint) (m :: * -> *) b. Monad m => (forall a. c a => a -> m b) -> ConstrList c -> m () To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In the type signature for ‘constrMapM_’: constrMapM_ :: Monad m => (forall a. c a => a -> m b) -> ConstrList c -> m () Failed, modules loaded: none. }}} If I add `AllowAmbiguousTypes`, it works when the definition is `undefined` but it doesn't work if I put the real definition in. I believe that this is accepted and works as I had intended on 7.8.3 (with the correct definition as well) after talking to some people on IRC, but I haven't personally tested it. bitemyapp on IRC noticed that it does compile on 7.10.1 if we add an extra argument of type `b` to both `constrMap_` and `constrMapM` and pass that value from `constrMapM_` to `constrMap` (I think all of those things must happen in order for this to work): {{{#!hs constrMapM :: Monad m => b -> (forall a. c a => a -> m b) -> ConstrList c -> m [b] constrMapM ignoredB f = sequence . constrMap f constrMapM_ :: Monad m => b -> (forall a. c a => a -> m b) -> ConstrList c -> m () constrMapM_ b f xs = fmap (const ()) (constrMapM b f xs) }}} Is this expected behavior? I don't fully understand the new ambiguity check. This kind of reminds me of linear types (or a relevant type system) in a way: we must make explicit use of the `b` to "discharge" it in order to have a valid type. Also, I notice that this works fine as well, which makes me think it the type error above is related to `ConstraintKinds`: {{{#!hs data AnyList f = forall a. (f a) :| (AnyList f) | Nil infixr :| anyMap :: (forall a. f a -> b) -> AnyList f -> [b] anyMap f (x :| xs) = f x : anyMap f xs anyMap _ Nil = [] anyMapM :: Monad m => (forall a. f a -> m b) -> AnyList f -> m [b] anyMapM f xs = sequence (anyMap f xs) anyMapM_ :: Monad m => (forall a. f a -> m b) -> AnyList f -> m () anyMapM_ f xs = fmap (const ()) (anyMapM f xs) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10651> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5