This ticket arises from a brief email thread http://www.haskell.org/pipermail/glasgow-haskell-users/2011-June/020550.html and http://www.haskell.org/pipermail/glasgow-haskell-users/2011-July/020564.html In a Template Haskell quasiquote, what would you expect this to do? ``` [myparser|blah\1blah|] ``` That is, what `String` would you expect to be passed to the parser `myparser`? Currently you get exactly the 10-character string ``` blah\1blah ``` The backslash is passed on literally. **The principle is to do as little meddling as possible, leaving it up to `myparser` to do what it wants.** However, backslash does initiate some limited escape behaviour ``` [myparser|blah\|blah|] -- gives "blah|blah" (9 chars) [myparser|blah\|]blah|] -- gives "blah|]blah" (10 chars) [myparser|blah\]blah|] -- gives "blah]blah" (9 chars) ``` The motivation here is that you might want the sequence "\|\]" in your quoted string, and to do so you have to escape it. However: - Currently "`\]`" is an escape sequence, but it does not need to be. - Currently "`\|`" is an escape sequence, whereas it could be "`\|]`". Then `[myparser|blah\|blah|]` would yield the (10-char) string `blah\|blah`. - There is no way to have a quote that ends in a backslash, thus `[myparser|\blahblah\|]`. This could be fixed by adding "`\\`" as an escape sequence for backslash. An alterntive would be to support no escapes at all, but instead ask `myparser` itself to determine where the quotation ended. Instead of `String -> Q Exp` the parser would have type `String -> Q (String,Exp)`. This seems to me to be a bridge too far. Better to get GHC to determine where the quote ends. Proposal: - Get rid of "`\]`" as an escape sequence - Replace "`\]`" as an escape sequence by "`\|]`" - Add "`\\`" as an escape sequence <details><summary>Trac metadata</summary> | Trac field | Value | | ---------------------- | ---------------------------------------------------------------- | | Version | 7.0.3 | | Type | Bug | | TypeOfFailure | OtherFailure | | Priority | normal | | Resolution | Unresolved | | Component | Compiler | | Test case | | | Differential revisions | | | BlockedBy | | | Related | | | Blocking | | | CC | gale@sefer.org;mainland@eecs.harvard.edu; kfisher@eecs.tufts.edu | | Operating system | | | Architecture | | </details> <!-- {"blocked_by":[],"summary":"Template Haskell quasiquote escapes","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["gale@sefer.org;mainland@eecs.harvard.edu; kfisher@eecs.tufts.edu"],"type":"Bug","description":"This ticket arises from a brief email thread\r\nhttp://www.haskell.org/pipermail/glasgow-haskell-users/2011-June/020550.html and http://www.haskell.org/pipermail/glasgow-haskell-users/2011-July/020564.html\r\n\r\nIn a Template Haskell quasiquote, what would you expect this to do?\r\n{{{\r\n [myparser|blah\\1blah|]\r\n}}}\r\nThat is, what `String` would you expect to be passed to the parser `myparser`? Currently you get exactly the 10-character string\r\n{{{\r\nblah\\1blah\r\n}}}\r\nThe backslash is passed on literally. '''The principle is to do as little meddling as possible, leaving it up to `myparser` to do what it wants.''' However, backslash does initiate some limited escape behaviour\r\n{{{\r\n [myparser|blah\\|blah|] -- gives \"blah|blah\" (9 chars)\r\n [myparser|blah\\|]blah|] -- gives \"blah|]blah\" (10 chars)\r\n [myparser|blah\\]blah|] -- gives \"blah]blah\" (9 chars)\r\n}}}\r\nThe motivation here is that you might want the sequence \"|]\" in your quoted string, and to do so you have to escape it. \r\n\r\nHowever:\r\n * Currently \"`\\]`\" is an escape sequence, but it does not need to be.\r\n\r\n * Currently \"`\\|`\" is an escape sequence, whereas it could be \"`\\|]`\". Then `[myparser|blah\\|blah|]` would yield the (10-char) string `blah\\|blah`.\r\n\r\n * There is no way to have a quote that ends in a backslash, thus `[myparser|\\blahblah\\|]`. This could be fixed by adding \"`\\\\`\" as an escape sequence for backslash.\r\n\r\nAn alterntive would be to support no escapes at all, but instead ask `myparser` itself to determine where the quotation ended. Instead of `String -> Q Exp` the parser would have type `String -> Q (String,Exp)`. This seems to me to be a bridge too far. Better to get GHC to determine where the quote ends.\r\n\r\nProposal:\r\n * Get rid of \"`\\]`\" as an escape sequence\r\n * Replace \"`\\]`\" as an escape sequence by \"`\\|]`\"\r\n * Add \"`\\\\`\" as an escape sequence","type_of_failure":"OtherFailure","blocking":[]} -->