#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): Just to address the second point here, the transformations that the renamer does for ApplicativeDo really are just annotations, not actual transformations, in the sense that you can easily get back the original program by just flattening out the `ApplicativeStmt`. It's done this way for exactly the reason you mentioned Simon - the typechecker needs to typecheck the code the user wrote. We also have to collect enough pieces that the desugarer can build the transformed Core expression, so the ApplicativeStmt has all the <$>, <*> and return identifiers. In the renamer there's an ad-hoc algorithm to group the `let` statements with the other statements in a `do`. I was never really happy with this, but it's important to do *something* otherwise `let` statements cause a loss of parallelism. We have tests for this - see `test9` in `testsuite/tests/ado/ado001.hs`. The paper doesn't deal with `let` unfortunately because we didn't include `let` statements in the grammar. It would be nice to fully understand and document what we do here. I also have a suspicion that we're not treating the last statement of the `do` in the way that the paper suggests - adding an extra `return` statement if the last statement is not a `return`. I think I was just lazy, because doing it in the way the paper suggests but without actually transforming the code (see discussion above) is a bit tricky. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11982#comment:15 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler