Perhaps a more low-tech solutions would be to just add haddock comments on the functions that make it obvious that you are looking at the internal versoin (e.g., something like -- | INTERNAL
).
I'd add Stmt
for making do
expressions to @michaelpj 's list. Indeed adding support for splicing in lists would take care of many use cases---I've only used the feature in Rust, and it certainly handy, if a bit hard to read with their notation.
If someone is looking to extend the TH quoting notation, here is another thing to ponder:
conP x
or varP x
). At present we can write [p| $x |]
but that requires x
to be a Pat
, not a name. Even if we allowed some sort of overloading, this doesn't work because there are two possible choices: variable pattern or constructor pattern. I guess we could add more information to Name
(i.e., constructor vs. variable), not sure.I agree with @sgraf812 that better quoting notation is likely to remove some of the needs to splice in things manually, but I am a bit skeptical that we can eliminate it entirely---there just seem to be too many syntactic constructs that one might want to be dynamic about. With this in mind, having a plan for some sort stability (not absolute) seems like a good idea.
SCC pragmas are not supported by Template Haskell. This make it impossible to properly profile a program, where part of the code is generate with TH.
Type [d| {-# SCC x #-}; x = () |]
in ghci
Generate a splice annotated with an SCC pragma.
Optional:
It's been a while since I looked at this code, but it seems to me that the question here is one of design (i.e., how we'd like it to work). The change seems reasonable to me. The main trade off I can think of, is that if one made a genuine mistake in the RHS of a type synonym, the error would only be reported at the use site.
Could you add an example of when the super-class constraint would be useful?