#10047: inconsistency in name binding between splice and quasiquotation -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"f46360ed7139ff25741b381647b0a0b6d1000d84/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="f46360ed7139ff25741b381647b0a0b6d1000d84" Refactor the handling of quasi-quotes As Trac #10047 points out, a quasi-quotation [n|...blah...|] is supposed to behave exactly like $(n "...blah..."). But it doesn't! This was outright wrong: quasiquotes were being run even inside brackets. Now that TH supports both typed and untyped splices, a quasi-quote is properly regarded as a particular syntax for an untyped splice. But apart from that they should be treated the same. So this patch refactors the handling of quasiquotes to do just that. The changes touch quite a lot of files, but mostly in a routine way. The biggest changes by far are in RnSplice, and more minor changes in TcSplice. These are the places where there was real work to be done. Everything else is routine knock-on changes. * No more QuasiQuote forms in declarations, expressions, types, etc. So we get rid of these data constructors * HsBinds.QuasiQuoteD * HsExpr.HsSpliceE * HsPat.QuasiQuotePat * HsType.HsQuasiQuoteTy * We get rid of the HsQuasiQuote type altogether * Instead, we augment the HsExpr.HsSplice type to have three consructors, for the three types of splice: * HsTypedSplice * HsUntypedSplice * HsQuasiQuote There are some related changes in the data types in HsExpr near HsSplice. Specifically: PendingRnSplice, PendingTcSplice, UntypedSpliceFlavour. * In Hooks, we combine rnQuasiQuoteHook and rnRnSpliceHook into one. A smaller, clearer interface. * We have to update the Haddock submodule, to accommodate the hsSyn changes }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10047#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10047: inconsistency in name binding between splice and quasiquotation -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.8.4 Resolution: fixed | 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): This has broken the name resolution behavior for quasiquoters. Previously, this was valid (assuming "wow" is a quasiquoter producing a declaration): {{{ {-# LANGUAGE QuasiQuotes #-} thing = okay [wow|stuff|] okay = 3 }}} but now it produces an error: {{{ /tmp/runghcXXXX1804289383846930886.hs:3:9: error: Not in scope: ‘okay’ }}} because after this change, quasiquoters share the declaration order restrictions of splices. I have code that depends on the previous behavior, and I'm sure there's a lot more code out there that does as well, as this was one of the main advantages of using quasiquoters over regular splices. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10047#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#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 rwbarton): spinda: indeed, your example hints at a simpler manifestation of the bug; when `wow` runs in your program, `thing` is not accessible to `reify` (not in scope), whereas if you'd written a splice with `$(...)`, it would be in scope. Sorry to hear that your programs were broken by this fix, but can't you just move the quasiquotations upward in your file so that they aren't in the middle of any recursive definition groups (e.g., to the top of the file)? I'm pretty sure the main advantage of quasiquoters was supposed to be the succinct syntax, not an undocumented difference in scoping rules. If there's a real use case for a type of splice with different scoping, it doesn't particularly make language design sense to tie that difference to quasiquotes vs. traditional splices. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10047#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#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

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

Quasi-quoters may use anti-quotation:

{{{ xs = blah [wow| funny language `(reverse xs)` blah |] }}}

Is this a new feature? It doesn't seem to be present as of 7.10.1. (Apologies for the multiple consecutive replies.) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10047#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#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: -------------------------------------+------------------------------------- Changes (by slyfox): * cc: slyfox (added) Comment: I skimmed through testsuite failures on full validate today and found qq007 and qq008 failures: {{{#!hs [sf] ~/dev/git/ghc/testsuite/tests/quasiquotation/qq007:cat QQ.hs {-# LANGUAGE TemplateHaskell #-} module QQ where import Language.Haskell.TH.Quote import Language.Haskell.TH pq = QuasiQuoter { quoteDec = \_ -> [d| f x = x |], quoteType = \_ -> [t| Int -> Int |], quoteExp = \_ -> [| $(varE (mkName "x")) + 1::Int |], quotePat = \_ -> [p| Just x |] } [sf] ~/dev/git/ghc/testsuite/tests/quasiquotation/qq007:"/home/slyfox/dev/git/ghc/inplace/bin /ghc-stage2" --make Test -fforce-recomp -dcore-lint -dcmm-lint -dno- debug-output -no-user-package-db -rtsopts -fno-warn-tabs -fno-ghci-history -v0 Test.hs:6:1: error: The type signature for ‘f’ lacks an accompanying binding }}} Reid suggested this fix likely caused the change. Is it fine/expected? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10047#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#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 goldfire): Replying to [comment:13 slyfox]:

I skimmed through testsuite failures on full validate today and found qq007 and qq008 failures:

These failures are indeed due to this ticket -- we need to fix them up. But first, we have to decide what to do with this ticket in general. I have to say I find @spinda's arguments convincing. The idea that `[q|blah|]` is identical to `$(quoteDec q "blah")` is nice, but perhaps there is a reason for two separate mechanisms here. The splitting that @spinda is so worried about happens only for ''declaration'' splice/quasiquotes, so we could have the splices/quasiquote consistency for other contexts. With some careful documentation in the manual, I think it's not hard for users to understand this difference. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10047#comment:15 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#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: | Unknown/Multiple Type of failure: None/Unknown | Test Case: th/T10047 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): See #5463 for another scenario where having flexibility around the issue discussed here would be helpful. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10047#comment:17 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10047: inconsistency in name binding between splice and quasiquotation -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: spinda Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: th/T10047 Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1199 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"c8f623e305ec0a51ac2406a1f754d244e05b96f5/ghc" c8f623e3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c8f623e305ec0a51ac2406a1f754d244e05b96f5" Expand declaration QQs first (#10047) Declaration QuasiQuoters do not cause a group split like $(...) splices, and are run and expanded before other declarations in the group. Resolves the lingering issue with #10047, and fixes broken tests qq007 and qq008. Test Plan: validate Reviewers: goldfire, austin, bgamari Reviewed By: bgamari Subscribers: goldfire, simonpj, thomie, spinda Differential Revision: https://phabricator.haskell.org/D1199 GHC Trac Issues: #10047 }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10047#comment:19 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler