[GHC] #10047: inconsistency in name binding between splice and quasiquotation
GHC
ghc-devs at haskell.org
Thu Jul 16 09:45:08 UTC 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
More information about the ghc-tickets
mailing list