... | @@ -3,19 +3,19 @@ |
... | @@ -3,19 +3,19 @@ |
|
**Nota bene:** These changes have largely all been implemented in GHC 7.8 (although there are a few dangling tickets which are left.) When in doubt, look at the linked tickets.
|
|
**Nota bene:** These changes have largely all been implemented in GHC 7.8 (although there are a few dangling tickets which are left.) When in doubt, look at the linked tickets.
|
|
|
|
|
|
|
|
|
|
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.
|
|
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.
|
|
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.
|
|
Here's the [implementation page](template-haskell/typed) the describes how we are going to implement this stuff.
|
... | @@ -121,7 +121,7 @@ type of the quoted term. |
... | @@ -121,7 +121,7 @@ type of the quoted term. |
|
|
|
|
|
|
|
|
|
In TH we deliberately did not do this, because it restricts expressiveness; see
|
|
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
|
|
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.
|
|
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.
|
|
But still, it's a weakness and, for some users (stand up Jacques), a very serious weakness.
|
... | @@ -182,7 +182,7 @@ We can't sensibly typecheck the term without knowing what f's type signature |
... | @@ -182,7 +182,7 @@ We can't sensibly typecheck the term without knowing what f's type signature |
|
is, and we can't know that without expanding the splice.
|
|
is, and we can't know that without expanding the splice.
|
|
|
|
|
|
|
|
|
|
Here's a rather different example, [\#4364](https://gitlab.haskell.org//ghc/ghc/issues/4364):
|
|
Here's a rather different example, [\#4364](https://gitlab.haskell.org/ghc/ghc/issues/4364):
|
|
|
|
|
|
```wiki
|
|
```wiki
|
|
type N0 = $( [t| Z |] )
|
|
type N0 = $( [t| Z |] )
|
... | @@ -235,7 +235,7 @@ On the "make-it-weaker" front, here's what I propose: |
... | @@ -235,7 +235,7 @@ On the "make-it-weaker" front, here's what I propose: |
|
|
|
|
|
- **Cease typechecking TH quotes altogether**. Instead, to use GHC's terminology, we would *rename* a quote, but not *typecheck* it. The renaming pass ensures that the scope hygiene mechanisms would remain unchanged. By not attempting to typecheck we avoid all the tricky problems sketched above.
|
|
- **Cease typechecking TH quotes altogether**. Instead, to use GHC's terminology, we would *rename* a quote, but not *typecheck* it. The renaming pass ensures that the scope hygiene mechanisms would remain unchanged. By not attempting to typecheck we avoid all the tricky problems sketched above.
|
|
|
|
|
|
- **Add pattern splices and local declaration splices**, as requested in [\#1476](https://gitlab.haskell.org//ghc/ghc/issues/1476). For example
|
|
- **Add pattern splices and local declaration splices**, as requested in [\#1476](https://gitlab.haskell.org/ghc/ghc/issues/1476). For example
|
|
|
|
|
|
```wiki
|
|
```wiki
|
|
-- mkPat :: Q Pat -> Q Pat
|
|
-- mkPat :: Q Pat -> Q Pat
|
... | @@ -245,17 +245,17 @@ On the "make-it-weaker" front, here's what I propose: |
... | @@ -245,17 +245,17 @@ On the "make-it-weaker" front, here's what I propose: |
|
g x = let $(mkDecl 3) in ...
|
|
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.
|
|
- **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).
|
|
> 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
|
|
These changes would essentially implement the desires of those who say
|
... | @@ -554,9 +554,9 @@ typechecked. |
... | @@ -554,9 +554,9 @@ typechecked. |
|
## Part D: quasiquotation
|
|
## Part D: quasiquotation
|
|
|
|
|
|
|
|
|
|
This part is unrelated to the preceding proposals, and is responding to [\#4372](https://gitlab.haskell.org//ghc/ghc/issues/4372) and [\#2041](https://gitlab.haskell.org//ghc/ghc/issues/2041).
|
|
This part is unrelated to the preceding proposals, and is responding to [\#4372](https://gitlab.haskell.org/ghc/ghc/issues/4372) and [\#2041](https://gitlab.haskell.org/ghc/ghc/issues/2041).
|
|
|
|
|
|
- For [\#2041](https://gitlab.haskell.org//ghc/ghc/issues/2041), rather than the proposal made there, I think the nicest thing is for `Language.Haskell.TH` to expose a *Haskell* quasiquoter:
|
|
- For [\#2041](https://gitlab.haskell.org/ghc/ghc/issues/2041), rather than the proposal made there, I think the nicest thing is for `Language.Haskell.TH` to expose a *Haskell* quasiquoter:
|
|
|
|
|
|
```wiki
|
|
```wiki
|
|
parseHaskell :: QuasiQuoter
|
|
parseHaskell :: QuasiQuoter
|
... | @@ -580,14 +580,14 @@ This part is unrelated to the preceding proposals, and is responding to [\#4372] |
... | @@ -580,14 +580,14 @@ This part is unrelated to the preceding proposals, and is responding to [\#4372] |
|
>
|
|
>
|
|
> >
|
|
> >
|
|
> >
|
|
> >
|
|
> > See [\#4430](https://gitlab.haskell.org//ghc/ghc/issues/4430) for an excellent point about fixities.
|
|
> > See [\#4430](https://gitlab.haskell.org/ghc/ghc/issues/4430) for an excellent point about fixities.
|
|
> >
|
|
> >
|
|
> >
|
|
> >
|
|
>
|
|
>
|
|
|
|
|
|
- For [\#4372](https://gitlab.haskell.org//ghc/ghc/issues/4372), I'm a bit agnostic. There is no technical issue here; it's just about syntax. Read the notes on the ticket.
|
|
- For [\#4372](https://gitlab.haskell.org/ghc/ghc/issues/4372), I'm a bit agnostic. There is no technical issue here; it's just about syntax. Read the notes on the ticket.
|
|
|
|
|
|
- See [\#4429](https://gitlab.haskell.org//ghc/ghc/issues/4429) for a suggestion about reifying `Names`.
|
|
- See [\#4429](https://gitlab.haskell.org/ghc/ghc/issues/4429) for a suggestion about reifying `Names`.
|
|
|
|
|
|
---
|
|
---
|
|
|
|
|
... | @@ -598,4 +598,4 @@ This part is unrelated to the preceding proposals, and is responding to [\#4372] |
... | @@ -598,4 +598,4 @@ This part is unrelated to the preceding proposals, and is responding to [\#4372] |
|
This section collects other TH changes that I think should be done.
|
|
This section collects other TH changes that I think should be done.
|
|
|
|
|
|
|
|
|
|
- The `InfixE` constructor of `Syntax.Exp` should only allow a `Var` in the operator position. See Trac [\#4877](https://gitlab.haskell.org//ghc/ghc/issues/4877) |
|
- The `InfixE` constructor of `Syntax.Exp` should only allow a `Var` in the operator position. See Trac [\#4877](https://gitlab.haskell.org/ghc/ghc/issues/4877) |