What `reify` sees in Template Haskell

Reid Barton rwbarton at gmail.com
Fri Feb 13 20:32:53 UTC 2015

On Fri, Feb 13, 2015 at 12:43 PM, Francesco Mazzoli <f at mazzo.li> wrote:

> Hi Simon,
> On 13 February 2015 at 18:12, Simon Peyton Jones <simonpj at microsoft.com>
> wrote:
> > I don’t think it would be difficult to recover the old behaviour, but
> it's not clear to me that it would be a Good Thing.  A program that works
> today, and then does not work tomorrow because of some incidental change to
> the way type inference works, would not be a happy state of affairs.
> In much the same way, programs that rely on the memory representation
> that GHC uses for objects can be written with the provided unsafe
> functions.  In my view, if you make this danger clear, having those
> functions is much better than not having them.  And it seems like the
> Haskell environment generally agree with this view.

Right, but the users of such features understand that their programs may
break under future versions of GHC, and don't expect to have any particular
recourse if this happens.

And this is essentially what happened here. It doesn't make sense to ask
about the type of a variable in a TH splice when the result of that splice
might affect what type the variable has! Admittedly it was not documented
that the behavior of reify was undefined in this case, but I imagine that's
because nobody had considered this scenario (if they had, we'd have had the
7.8 design from the start).

I don't like it more than anyone else when GHC breaks user programs, but
when those programs were dependent on undefined behavior, I think it's
incumbent on the user to find a way to rewrite their program so as to not
depend on undefined behavior. This might include requesting a new GHC
feature with well-defined semantics. Adding the old undefined behavior
should be a last resort, and then in the future the undefined behavior
might stop giving you the answer you want anyways.

> In any case, if I think of some reasonable but more permissive
> restriction, I'll write it up.

Have you tried using Typed TH splices? Those interact differently with the
type checker, because the type of the expression resulting from a splice is
determined by the type of the splice action, and cannot depend upon its
value. So, it seems to me that it would be fine to allow reify to ask about
the type of a local variable from within a typed splice, and it may work
that way already (I haven't tried it).

Reid Barton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20150213/9a127f05/attachment.html>

More information about the ghc-devs mailing list