#13875: ApplicativeDo desugaring is lazier than standard desugaring -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:3 simonmar]:
To fix this properly we would have to prevent `ApplicativeDo` from applying to any statement with a strict pattern match. In practice I doubt anyone is going to write `~p` to make `ApplicativeDo` work, but fortunately it still works for simple variable patterns.
It seems terribly unfortunate, in my opinion, if adding a language extension to a module can, ''all by itself'', introduce a memory leak. The fix does seem annoying, but I don't think there's another good way. The current behavior is both surprising and inconsistent. We generally expect, for example, that {{{#!hs (x,y) <- m e }}} will be exactly the same as {{{#!hs xy <- m case xy of (x,y) -> e }}} but that's not currently the case. Here's an (arguably) more extreme example: {{{#!hs oops m = do !xy <- m pure (fst xy + snd xy) }}} With `ApplicativeDo`, the bang pattern is silently ignored. So I think the special desugaring should only be used if all the patterns are lazy. It might make sense to check whether an expression could ''otherwise'' be desugared specially, and offer an optional warning in that case. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13875#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler