[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):

 Yet another few thoughts. This is a situation that could be improved
 offering, in addition, separate `ado` syntax. Such syntax would offer
 deeply-lazy-always pattern matching, prohibit inappropriate bangs, and
 throw an error if desugaring would require `>>=`. Along with setting
 laziness appropriately, this would allow the user to declare that they
 expect applicative optimizations to kick in, even when a monad is actually
 available.

 While I'm mentioning idle thoughts: monad comprehension syntax seems to
 handle the `pure`/`return`/`pure $`/whatever issue a lot more cleanly than
 anything `do`-like. Has anyone considered applicative comprehensions?

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13875#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler