Accept expressions in left-hand side of quasiquotations
|Reported by:||simonpj||Owned by:|
|Keywords:||Cc:||kfisher@…, gershomb@…, michael@…, pho@…|
|Type of failure:||None/Unknown||Test Case:|
|Related Tickets:||Differential Rev(s):|
Description (last modified by )
Gershom Bazerman (gershomb@…) writes: Attached is an experimental patch (not read for prime-time) that extends quasiquotation syntax. At the moment, quasiquoters can only be single identifiers of type
QuasiQuoter (and of course declared outside the current module). This patch allows an entire expression of type
QuasiQuoter in the quoter position. The staging restriction is extended to all free variables in the quasiquoter expression.
qq1 :: Int -> QuasiQuoter, one can now write
[$qq1 12 | ... |]
This syntax would be quite useful for my own project (jmacro), and from discussions at ICFP, to others who also are beginning to take serious advantage of quasiquotation.
Here's one use case. Suppose jmt is a
QuasiQuoters parameterized with each successive typing environment.
There are a number of tricky choices made in this patch, not all of which are perhaps correct.
First, currently, the quoter and quotation are lexed and parsed as a single token. To avoid reinvoking the lexer and/or parser, now '[$' is lexed as one token, and a flag is set in the lexer state which lexes the
|...|] (i.e. the quotation) as a single quotation on encountering the first vbar. This means that guards can't be used inside a quasiquoter expression -- i.e.
[$let x | True = 1 in qq1 x|..|] would fail to parse. This also means that while now in ghc 7, one can write
[qq|..], to parse a full expression rather than identifier, we need the dollar sign as well.
The former problem (stealing guards within quasiquoter expressions) can be fixed by a syntax change which moves from a single vbar to a new symbol (perhaps
|| ?) to signal the transition between the quoter expression and the quote itself. I tend to feel that the loss of guards within quasiquoter expressions is not too painful, however. Adding a new symbol between quoter and quotee also would simplify the necessary changes to the lexer, removing the need to set a special flag in the lexer state.
The second problem (need to reintroduce a dollar) is somewhat irritating, but not terribly so. One could either introduce the dollar in all cases, which allows simplifying the lexer and parser, or keep the dollarless syntax as well for single identifiers, which adds both complexity and duplicate syntax, but keeps the default case especially lightweight.
The patch as it stands introduces "extended quasiquotations" as an orthogonal change that doesn't affect the existing quasiquotation machinery, and, at the moment, only allows for quasiquotations of expressions (i.e., not patterns, etc.).
If there is sentiment that this is useful and could be accepted, modulo whatever requested tweaks, I'd be happy to do whatever work is necessary -- implementing changes, adding documentation, pushing the changes through to quasiquoters in other positions, etc.
Change History (26)
comment:23 Changed 22 months ago by
|Summary:||Extending quasiquotation support → Accept expressions in left-hand side of quasiquotations|