It was pointed out by Ben Millwood on the Cafe that there is an undocumented way to escape the closing oxford bracket of a quasi-quote using a backslash: [s|This quasi-quote contains this, \|], an escaped closing oxford bracket.|] The backslash itself cannot be escaped in this way: [s|Also contains an escaped bracket \\|] |] Thus there is a fairly strong limitation on the contents of a quasi-quote: it can never end in a backslash. This behavior is not mentioned in the GHC docs. Is it a mistake, or is it meant to be a supported feature? This behavior is a bit surprising to me. Since the whole point of a quasi-quoter is to allow the user to define syntax, you would think that the syntax for the quasi-quote itself would be as quiet as possible and stay out of the way. People who need to be able to escape the closing bracket can easily define their own syntax to do so. In any case, if this is indeed a feature, it certainly should be documented. Thanks, Yitz
On 30/06/2011 14:52, Yitzchak Gale wrote:
It was pointed out by Ben Millwood on the Cafe that there is an undocumented way to escape the closing oxford bracket of a quasi-quote using a backslash:
[s|This quasi-quote contains this, \|], an escaped closing oxford bracket.|]
The backslash itself cannot be escaped in this way:
[s|Also contains an escaped bracket \\|] |]
Thus there is a fairly strong limitation on the contents of a quasi-quote: it can never end in a backslash.
This behavior is not mentioned in the GHC docs. Is it a mistake, or is it meant to be a supported feature?
This behavior is a bit surprising to me. Since the whole point of a quasi-quoter is to allow the user to define syntax, you would think that the syntax for the quasi-quote itself would be as quiet as possible and stay out of the way. People who need to be able to escape the closing bracket can easily define their own syntax to do so.
In any case, if this is indeed a feature, it certainly should be documented.
It looks intentional to me: lex_quasiquote :: String -> P String lex_quasiquote s = do i <- getInput case alexGetChar' i of Nothing -> lit_error i Just ('\\',i) | Just ('|',i) <- next -> do setInput i; lex_quasiquote ('|' : s) | Just (']',i) <- next -> do setInput i; lex_quasiquote (']' : s) where next = alexGetChar' i Just ('|',i) | Just (']',i) <- next -> do setInput i; return s where next = alexGetChar' i Just (c, i) -> do setInput i; lex_quasiquote (c : s) Indeed, it also seems strange that "\\]" is interpreted as "]". That's all I know. I agree we should either document or remove the feature. Cheers, Simon
Dear Template Haskell users There was a little exchange about TH quasiquotes a few weeks back (see below). I've made a ticket and some concrete proposals here http://hackage.haskell.org/trac/ghc/ticket/5348 Do take a look, if you care about TH quasiquotes. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Simon Marlow | Sent: 11 July 2011 13:43 | To: gale@sefer.org | Cc: GHC users; Ben Millwood | Subject: Re: Quoting a quasi-quote | | On 30/06/2011 14:52, Yitzchak Gale wrote: | > It was pointed out by Ben Millwood on the Cafe | > that there is an undocumented way to escape the | > closing oxford bracket of a quasi-quote using | > a backslash: | > | > [s|This quasi-quote contains this, \|], an escaped | > closing oxford bracket.|] | > | > The backslash itself cannot be escaped in this | > way: | > | > [s|Also contains an escaped bracket \\|] |] | > | > Thus there is a fairly strong limitation on the | > contents of a quasi-quote: it can never end | > in a backslash. | > | > This behavior is not mentioned in the GHC docs. | > Is it a mistake, or is it meant to be a supported | > feature? | > | > This behavior is a bit surprising to me. Since the | > whole point of a quasi-quoter is to allow the user | > to define syntax, you would think that the syntax | > for the quasi-quote itself would be as quiet as | > possible and stay out of the way. People who | > need to be able to escape the closing bracket | > can easily define their own syntax to do so. | > | > In any case, if this is indeed a feature, it certainly | > should be documented. | | It looks intentional to me: | | lex_quasiquote :: String -> P String | lex_quasiquote s = do | i <- getInput | case alexGetChar' i of | Nothing -> lit_error i | | Just ('\\',i) | | Just ('|',i) <- next -> do | setInput i; lex_quasiquote ('|' : s) | | Just (']',i) <- next -> do | setInput i; lex_quasiquote (']' : s) | where next = alexGetChar' i | | Just ('|',i) | | Just (']',i) <- next -> do | setInput i; return s | where next = alexGetChar' i | | Just (c, i) -> do | setInput i; lex_quasiquote (c : s) | | | Indeed, it also seems strange that "\\]" is interpreted as "]". | | That's all I know. I agree we should either document or remove the feature. | | Cheers, | Simon | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Hi,
I have an alternative suggestion, please let me know what you think.
We introduce an alternative start tag i.e. a quote can start with [q|
or [q\| (or something similar). If [q| is used then the quoted text is
used verbatim and if the alternative start-tag is used then the escape
sequences suggested (\\ and \|]) are enabled.
Examples:
These are all as in the current implementation:
[q|nothing special|]
[q|a \ in the text|] (uses "a \\ in the text")
These is an incompatible change:
[q|a \|] |] will be a parse error, is currently "a |] "
These are all parse errors (I believe) that will work:
[q|a \|] will use "a \\"
[q\|nothing special|] will use "nothing special"
[q\|a \\ in the text|] will use "a \\ in the text"
[q\|both \|] and \\|] will use "both |] and \\"
Also [q\|a \ in the text|] should be a parse error, i.e. all
backslashes must be escape sequences when using the alternative tag.
Arguably the incompatible change could be removed, but then the
alternative tag must be used to end a quote with backslash and it
seems cleaner to have one fully verbatim and one fully escapable tag.
One advantage of this approach is that we can add more escape
sequences in the future without breaking code (since all backslash
sequences are reserved in the alternative tag).
Regards,
Jonas
On 27 July 2011 08:56, Simon Peyton-Jones
Dear Template Haskell users
There was a little exchange about TH quasiquotes a few weeks back (see below). I've made a ticket and some concrete proposals here http://hackage.haskell.org/trac/ghc/ticket/5348
Do take a look, if you care about TH quasiquotes.
Simon
| -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Simon Marlow | Sent: 11 July 2011 13:43 | To: gale@sefer.org | Cc: GHC users; Ben Millwood | Subject: Re: Quoting a quasi-quote | | On 30/06/2011 14:52, Yitzchak Gale wrote: | > It was pointed out by Ben Millwood on the Cafe | > that there is an undocumented way to escape the | > closing oxford bracket of a quasi-quote using | > a backslash: | > | > [s|This quasi-quote contains this, \|], an escaped | > closing oxford bracket.|] | > | > The backslash itself cannot be escaped in this | > way: | > | > [s|Also contains an escaped bracket \\|] |] | > | > Thus there is a fairly strong limitation on the | > contents of a quasi-quote: it can never end | > in a backslash. | > | > This behavior is not mentioned in the GHC docs. | > Is it a mistake, or is it meant to be a supported | > feature? | > | > This behavior is a bit surprising to me. Since the | > whole point of a quasi-quoter is to allow the user | > to define syntax, you would think that the syntax | > for the quasi-quote itself would be as quiet as | > possible and stay out of the way. People who | > need to be able to escape the closing bracket | > can easily define their own syntax to do so. | > | > In any case, if this is indeed a feature, it certainly | > should be documented. | | It looks intentional to me: | | lex_quasiquote :: String -> P String | lex_quasiquote s = do | i <- getInput | case alexGetChar' i of | Nothing -> lit_error i | | Just ('\\',i) | | Just ('|',i) <- next -> do | setInput i; lex_quasiquote ('|' : s) | | Just (']',i) <- next -> do | setInput i; lex_quasiquote (']' : s) | where next = alexGetChar' i | | Just ('|',i) | | Just (']',i) <- next -> do | setInput i; return s | where next = alexGetChar' i | | Just (c, i) -> do | setInput i; lex_quasiquote (c : s) | | | Indeed, it also seems strange that "\\]" is interpreted as "]". | | That's all I know. I agree we should either document or remove the feature. | | Cheers, | Simon | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
participants (4)
-
Jonas Almström Duregård -
Simon Marlow -
Simon Peyton-Jones -
Yitzchak Gale