[GHC] #10047: inconsistency in name binding between splice and quasiquotation

[GHC]

#10047: inconsistency in name binding between splice and quasiquotation
-------------------------------------+-------------------------------------
        Reporter:  rwbarton          |                   Owner:
            Type:  bug               |                  Status:  new
        Priority:  normal            |               Milestone:  7.12.1
       Component:  Template Haskell  |                 Version:  7.8.4
      Resolution:                    |                Keywords:
Operating System:  Unknown/Multiple  |            Architecture:
 Type of failure:  None/Unknown      |  Unknown/Multiple
      Blocked By:                    |               Test Case:  th/T10047
 Related Tickets:                    |                Blocking:
                                     |  Differential Revisions:
-------------------------------------+-------------------------------------

Comment (by spinda):

 Firstly, at least as far as I've seen, the scoping restriction is one of
 the most common complaints about Template Haskell splices, as using them
 at all suddenly causes order of declaration to matter where it didn't
 before. This contributes to the stigma and avoidance of Template Haskell
 usage. It would be a shame to see quasiquoters get shackled with this
 issue as well.

 Then, I think it's important to consider the role of quasiquoters as
 enabling extensions to the language without requiring compiler plugins,
 external preprocessors, or what have you, while keeping them contained
 from the rest of the Haskell source around them. As a specific example,
 I'll pull from my current GSoC project, which is impacted by this change
 (and, to be honest, is the reason I ran into this).

 I have an {{{lq}}} quasiquoter which allows for LiquidHaskell type
 signatures and specifications to be attached to variables and types. In
 the declaration context, it parses a subset of Haskell with LiquidHaskell
 extensions and emits declarations and annotations. Take some vanilla
 Haskell code:

 {{{
 module Test () where

 type Nat = Int

 add :: Nat -> Nat -> Nat
 add x y = id' $ x + y

 id' :: a -> a
 id' x = x
 }}}

 A little contrived, but not too far from what you'd run into in
 sufficiently complex real-world projects. Under the current (or, previous)
 quasiquoter implementation, extending this existing code with custom
 annotations is a fairly straightforward translation:

 {{{
 {-# LANGUAGE QuasiQuotes #-}

 module Test () where

 import LiquidHaskell

 [lq| type Nat = { v:Int | 0 <= v } |]

 [lq| add :: Nat -> Nat -> Nat |]
 add x y = id' $ x + y

 [lq| id' :: x:a -> { v:a | v == a } |]
 id' x = x
 }}}

 But after this change, introducing these annotations suddenly makes order
 of declaration matter. What were lightweight inline extensions to the
 language now require restructuring of code, either reordering the
 functions themselves or moving all signatures and specifications to the
 top of every file. Needless to say, this makes the whole thing much less
 attractive.

 And, frankly, this is what quasiquoters are all about: lightweight, inline
 language extensions that don't interfere with the rest of the code. This
 intent is reflected in the original paper. With this restriction imposed,
 anything using quasiquoters suddenly brings in a lot more baggage than it
 used to, discouraging use. It's not just a matter of modifying some
 existing code to fit, it's that this hampers a whole set of use-cases for
 which quasiquoters (a) used to fit quite nicely and (b) are the only real
 solution at present.

 Quietly breaking this behavior of 12 years now in a tangentially related
 bugfix strikes me as, well, wrong, especially when there isn't an
 alternative available. Excuse me if I seem rather passionate about this
 issue.

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