[GHC] #13875: ApplicativeDo desugaring is lazier than standard desugaring

[GHC]

#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