... | ... | @@ -6,16 +6,16 @@ |
|
|
This page explores a set of design proposals for Template Haskell. They are inspired by discussion with Tim Sheard, Kathleen Fisher, and Jacques Carette. It was originally triggered by several Template Haskell tickets: including [\#4230](https://gitlab.haskell.org//ghc/ghc/issues/4230), [\#4135](https://gitlab.haskell.org//ghc/ghc/issues/4135), [\#4128](https://gitlab.haskell.org//ghc/ghc/issues/4128), [\#4170](https://gitlab.haskell.org//ghc/ghc/issues/4170), [\#4125](https://gitlab.haskell.org//ghc/ghc/issues/4125), [\#4124](https://gitlab.haskell.org//ghc/ghc/issues/4124), [\#4364](https://gitlab.haskell.org//ghc/ghc/issues/4364), [\#6062](https://gitlab.haskell.org//ghc/ghc/issues/6062), [\#6089](https://gitlab.haskell.org//ghc/ghc/issues/6089). (See also [\#7016](https://gitlab.haskell.org//ghc/ghc/issues/7016), which work better with the suggestions below.) Taken together, these proposals would make quite a big change to TH, I think for the better. Happily, I'm pretty sure they are relatively easy to implement.
|
|
|
|
|
|
|
|
|
The page was originally [ this blog post](http://hackage.haskell.org/trac/ghc/blog/Template%20Haskell%20Proposal), but has moved here so that others can edit it.
|
|
|
The page was originally [this blog post](http://hackage.haskell.org/trac/ghc/blog/Template%20Haskell%20Proposal), but has moved here so that others can edit it.
|
|
|
|
|
|
|
|
|
There's an interesting [ critique of Template Haskell](http://stackoverflow.com/questions/10857030/whats-so-bad-about-template-haskell) on StackOverflow, some (but not all) of which is addressed by proposals here.
|
|
|
There's an interesting [critique of Template Haskell](http://stackoverflow.com/questions/10857030/whats-so-bad-about-template-haskell) on StackOverflow, some (but not all) of which is addressed by proposals here.
|
|
|
|
|
|
|
|
|
But I'd like to get the design right; hence this post. I'm going to treat it as a working draft, and modify it in the light of comments. So please comment.
|
|
|
|
|
|
|
|
|
I'm going to assume that you are more or less familiar with Template Haskell. If not, there's lots of background on the [ Template Haskell page](http://www.haskell.org/haskellwiki/Template_Haskell). It's a Wiki so you can help to improve it.
|
|
|
I'm going to assume that you are more or less familiar with Template Haskell. If not, there's lots of background on the [Template Haskell page](http://www.haskell.org/haskellwiki/Template_Haskell). It's a Wiki so you can help to improve it.
|
|
|
|
|
|
|
|
|
Here's the [implementation page](template-haskell/typed) the describes how we are going to implement this stuff.
|
... | ... | @@ -118,7 +118,7 @@ type of the quoted term. |
|
|
|
|
|
|
|
|
In TH we deliberately did not do this, because it restricts expressiveness; see
|
|
|
[ the original TH paper](http://research.microsoft.com/en-us/um/people/simonpj/papers/meta-haskell/index.htm).
|
|
|
[the original TH paper](http://research.microsoft.com/en-us/um/people/simonpj/papers/meta-haskell/index.htm).
|
|
|
We could make this choice without losing soundness because in TH, unlike in MetaML, all splicing is
|
|
|
done at compile time, and the result of a splice is typechecked from scratch.
|
|
|
But still, it's a weakness and, for some users (stand up Jacques), a very serious weakness.
|
... | ... | @@ -242,14 +242,14 @@ On the "make-it-weaker" front, here's what I propose: |
|
|
g x = let $(mkDecl 3) in ...
|
|
|
```
|
|
|
|
|
|
These are not supported today because they bring new variables into scope, and hence are incompatible with running splices only after the renamer is finished; see [ Notes on Template Haskell](http://research.microsoft.com/~simonpj/tmp/notes2.ps), section 8.
|
|
|
These are not supported today because they bring new variables into scope, and hence are incompatible with running splices only after the renamer is finished; see [Notes on Template Haskell](http://research.microsoft.com/~simonpj/tmp/notes2.ps), section 8.
|
|
|
|
|
|
- **Run TH splices in the renamer**, uniformly with quasi-quotes. Of course, we must still typecheck the code we are about to run. But there's an *existing* TH restriction that code run in top-level splices must be imported. So we can typecheck this code even during renaming, because it can only mention imported (and hence already fully-typechecked) code.
|
|
|
|
|
|
>
|
|
|
> This solves [\#4364](https://gitlab.haskell.org//ghc/ghc/issues/4364) because we run the splice in the renamer, so things are sorted out by the time we are checking for cycles (in the type checker).
|
|
|
|
|
|
- **Allow quoted names as patterns** as [ requested by Conal Eliott](http://www.haskell.org/pipermail/libraries/2012-January/017449.html). This is just a variation on allowing splices in patterns, since a quoted name `'x` is really just a simple splice
|
|
|
- **Allow quoted names as patterns** as [requested by Conal Eliott](http://www.haskell.org/pipermail/libraries/2012-January/017449.html). This is just a variation on allowing splices in patterns, since a quoted name `'x` is really just a simple splice
|
|
|
|
|
|
|
|
|
These changes would essentially implement the desires of those who say
|
... | ... | |