Opened 8 months ago

Last modified 8 months ago

#16177 new feature request

Rename Q (TExp a) to Code a

Reported by: mpickering Owned by:
Priority: normal Milestone:
Component: Template Haskell Version: 8.6.3
Keywords: TypedTemplateHaskell Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

I propose that we modify the typed template haskell API so that quoting an expression of type t results in a value of type Code t rather than Q (TExp a) and the splice construct requires an argument of type Code a to produce a value of type a.

The definition of Code is as follows.

newtype Code a = Code (Q (TExp a))

There are two good reasons to do this.

  1. Q (TExp a) is ugly and leaks implementation details to the user. Using effects from the Q monad is unsafe and against the principle of staged programming.
  2. Writing instances for Q (TExp a) is quite difficult. It's much easier when the newtype is defined but at the cost of constant wrapping and unwrapping.

Change History (4)

comment:1 Changed 8 months ago by goldfire

This also (in reference to #16176) might be a ghc-proposal. What operations in the Q monad are unsafe? Surely not lookups. Perhaps you mean unsafe in the sense that they aren't reflected in typed TH? I'm really not sure.

comment:2 Changed 8 months ago by mpickering

Unsafe meaning that running a splice can fail in any manner.

Under that definition there are a few unsafe operations qAddTopDecls, qRunIO, qReport come immediately to mind.

The other qReify* operations should be discouraged as well as they go against how people should be writing their typed template haskell programs (in my opinion). Dispatching based of these I guess is possible in a safe manner but I'm not sure how you could do much usefully as you have to construct a Name in order to use them.

comment:3 Changed 8 months ago by goldfire

I still say this is best debated in a ghc-proposal. There are significant design/policy decisions here that will benefit from a broad audience.

comment:4 Changed 8 months ago by mpickering

I agree with you Richard. I'll get around to it along with #16176.

Note: See TracTickets for help on using tickets.