#11982: Typechecking fails for parallel monad comprehensions with polymorphic let (GHC 7.10.3 through 8.6.3) -------------------------------------+------------------------------------- Reporter: simonpj | Owner: josefs Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: ApplicativeDo 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: | -------------------------------------+------------------------------------- Comment (by simonmar): Actually I do think that `ApplicativeDo` has a similar problem to parallel list comprehensions. It's true that in the example given in comment:5 above we could fix `ApplicativeDo` to do a slightly different transformation and not run into the problem. But that won't work in general, e.g. {{{ test :: IO (Int, Char, Int) test = do x <- return 'a' y <- return 'a' let f | y == 'c' = id | otherwise = id z <- return (f 3) return (f 3, f 'a', z) }}} This is accepted without `ApplicativeDo`, but rejected with it, because we need `f` to be polymorphic. The renamer produces: {{{ ==================== Renamer ==================== Test.test :: IO (Int, Char, Int) Test.test = do x_a3Dl <- return 'a' | (f_a3Dn, z_a3Do) <- do y_a3Dm <- return 'a' let f_a3Dn | y_a3Dm == 'c' = id | otherwise = id z_a3Do <- return (f_a3Dn 3) (f_a3Dn, z_a3Do) return (f_a3Dn 3, f_a3Dn 'a', z_a3Do) }}} so we would need to instantiate the tuple type with polymorphic arguments. Simon - I vaguely remember that we discussed this when reviewing the code for ApplicativeDo and we decided to punt on it at the time, but unfortunately I can't find any record of it, do you remember by any chance? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11982#comment:19 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler