Opened 12 years ago

Last modified 5 years ago

#2041 new feature request

Allow splicing in concrete syntax

Reported by: igloo Owned by:
Priority: normal Milestone:
Component: Template Haskell Version: 6.8.2
Keywords: Cc: mjm2002@…, reiner.pope@…, pho@…
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


Template Haskell tends to lag behind GHC extensions, so it might be nice to allow concrete syntax to be returned, e.g. something like

f = $( return (RawE "5 + 6") )

There wouldn't be any need to restrict it to the top level, e.g. this would also be allowed:

f = $( return (InfixE (IntE 5) '(+) (RawE "6")) )

One possible disadvantage is that it might result in TH languishing even further behind, as there is less incentive to fill in the gaps.

Also, if a module splices in a raw expression from a TH library, what extensions should be enabled when parsing the string? Should we use the extensions enabled for the module, or should the RawE constructor specify the extensions to be used? We actually have this problem already, as (for example) when instances are spliced in we might need OverlappingInstances enabled, so just using the extensions enabled for the module would be consistent.

Change History (10)

comment:1 Changed 12 years ago by simonpj

Type: bugfeature request

comment:2 Changed 11 years ago by simonmar

Architecture: UnknownUnknown/Multiple

comment:3 Changed 11 years ago by simonmar

Operating System: UnknownUnknown/Multiple

comment:4 Changed 11 years ago by morrow

Cc: mjm2002@… added

comment:5 Changed 11 years ago by igloo

Milestone: 6.10 branch_|_

comment:6 Changed 9 years ago by reinerp

Cc: reiner.pope@… added
Type of failure: None/Unknown

Another use for this would be for creating custom quasiquoters with antiquoting. Say, to create a custom list quasiquoter:

[list| x^2+y, 3*z |]

the quasiquoter needs to parse antiquoted expressions such as x^2+y and 3*z into TH abstract syntax. Current quasiquoters mostly do this using haskell-src-exts (via the haskell-src-meta library), but it would be neater just to return a RawE antiquoted_stuff expression.

comment:7 Changed 8 years ago by PHO

Cc: pho@… added

comment:8 Changed 5 years ago by ezyang

I'm not keen on reverting to strings for quasiquotes: if the problem is the template-haskell representation is not keeping up to date, let's do something about that, instead of falling back on strings.

One reason that we maintain the separate template-haskell library is to avoid having a dependency on the ghc-api for code that wants to use TH. If people are willing to compromise on that, we could make splices accept proper ghc-api AST returns, in which case we skip the TH conversion pass. There'd need to be a way to make ordinary quotes return ghc-api syntax trees rather than template-haskell syntax trees (either a reserved quasi-quote, or a language extension that applies to all quasiquotes).

This also works for reinerp's use-case, as you can use ghc-api to directly parse your code and then return it in a splice. (Of course, we'd want to make this a bit more stable.)

Last edited 5 years ago by ezyang (previous) (diff)

comment:10 Changed 5 years ago by ezyang

I decided to record this alternate proposal here: #10331

Note: See TracTickets for help on using tickets.