Opened 7 years ago

Last modified 5 weeks 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 Revisions:

Description

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 7 years ago by simonpj

  • Type changed from bug to feature request

comment:2 Changed 7 years ago by simonmar

  • Architecture changed from Unknown to Unknown/Multiple

comment:3 Changed 7 years ago by simonmar

  • Operating System changed from Unknown to Unknown/Multiple

comment:4 Changed 7 years ago by morrow

  • Cc mjm2002@… added

comment:5 Changed 6 years ago by igloo

  • Milestone changed from 6.10 branch to _|_

comment:6 Changed 5 years ago by reinerp

  • Cc reiner.pope@… added
  • Type of failure set to 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 3 years ago by PHO

  • Cc pho@… added

comment:8 Changed 6 weeks 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 6 weeks ago by ezyang (previous) (diff)

comment:10 Changed 5 weeks ago by ezyang

I decided to record this alternate proposal here: #10331

Note: See TracTickets for help on using tickets.