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

16 Jul 2015

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

 Regarding what I wrote earlier about the splicing restriction:

 There's an essential conflict between having module-local declarations in
 scope for the reification environment and avoiding the splitting of
 declaration groups on splices. For some splices, such as {{{makeLenses}}},
 reification takes precedence. But not all splices need to reify module-
 local declarations: for those, giving that up would be worth avoiding the
 splicing restriction.

 In 7.10, the first use case for splices is covered by the {{{$(...)}}}
 syntax, and the second by quasiquoters. After this change, only the first
 is represented.

 This can be rectified by providing some way to mark splices as falling
 into the second category, then processing them along with the other
 declarations in the group instead of splitting on them. To accomplish
 this, an additional {{{$$(...)}}} syntax (or similar) could be added. In
 the top-level declaration context, these splices would be marked as not to
 be split on. For consistency, the same syntax would yield the same result
 as {{{$(...)}}} in all other contexts (types, etc).

 Quasiquoters would then gain a similar additional syntax, {{{[:name| ...
 |]}}} or such. Since this would actually emulate the current behavior of
 quasiquoters, perhaps the effect should be reversed here for
 compatibility, with the second syntax ''enabling'' splitting. I'm not
 sure.

 Alternately, we could forgo the additional syntax and simply mark all
 splices arising from quasiquoters as not causing a split. This would
 accomplish the end goal of preserving compatibility.

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