#4372: Extending quasiquotation support -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 6.12.3 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 rwbarton): songzh: `'[' quoterExp '|' strings '|]'` is not really possible since it looks too much like any list comprehension. If you wrote `[ x * y | x <- [1,2,3], y <- [4,5] ]` is that a list comprehension or the beginning of a quasiquote, that might terminate arbitrarily far away? With quasiquotes as they stand now you cannot write a list comprehension like `[x|x<-[1,2,3]]`; you must include a non-identifier character before the `|`. That's a mild imposition, but it is already something, and I don't see how the syntax can be pushed much farther. As for the ticket in general: Quasiquotes offer two conveniences over TH splices: overloading the same name to refer to expression, pattern, etc. splice generators; and raw string literals (terminated by `|]`). The overloading can be nice, but is never essential (the resolution is purely syntactic anyway) and often you only need the expression quoter. The raw string literal syntax is quite useful, but it's a problem that only needs to be solved once. Specifically, once you have a quasiquoter `q` that produces string literals, you can rewrite any {{{ [foo|bar|] }}} as {{{ $(foo [q|bar|]) -- this 'foo' is the old 'quoteExp foo'. -- at worst, you could call it 'fooE' or something. }}} which is already not that much longer; and any syntax for parameterized quasiquoters would have to be longer than `[foo arg|bar|]`, so there's very little room left for improvement over what we can build with the pieces we have today. So basically I agree with Gershom: the workaround he suggested is always possible, it's pretty lightweight, and it's hard to see how a new syntax for this would really be worth it, when it can't gain much (and has the opportunity cost of not being able to use the syntax for something else). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/4372#comment:22 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler