[GHC] #4372: Extending quasiquotation support
GHC
ghc-devs at haskell.org
Sun Mar 8 18:46:35 UTC 2015
#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
More information about the ghc-tickets
mailing list