Fwd: Host-Oriented Template Haskell

[Edward Z. Yang]

Hello John

You may find this implementation ticket of interest:
https://ghc.haskell.org/trac/ghc/ticket/11378

Edward

Excerpts from Ericson, John's message of 2016-01-19 15:15:15 -0800:
> Cross-posting this as was suggested on the Haskell-Cafe list. While I
> envision this as normal feature that anyone can use, in practice its
> biggest consumers would be GHC devs.
> 
> John
> 
> ---------- Forwarded message ----------
> From: Ericson, John <john_ericson at brown.edu>
> Date: Tue, Jan 19, 2016 at 1:17 PM
> Subject: Host-Oriented Template Haskell
> To: Haskell-Cafe <haskell-cafe at haskell.org>
> 
> 
> As is well known, TH and cross-compiling do not get along. There are
> various proposals on how to make this interaction less annoying, and I
> am not against them. But as I see it, the problem is largely inherent
> to the design of TH itself: since values can (usually) be lifted from
> compile-time to run-time, and normal definitions from upstream modules
> to downstream modules' TH, TH and normal code must "live in the same
> world".
> 
> Now this restriction in turn bequeaths TH with much expressive power,
> and I wouldn't advocate getting rid of it. But many tasks do not need
> it, and in some cases, say in bootstrapping compilers[1] themselves,
> it is impossible to use TH because of it, even were all the current
> proposals implemented.
> 
> For these reason, I propose a new TH variant which has much harsher
> phase separation. Normal definitions from upstream modules can not be
> used, lifting values is either not permitted or is allowed to fail
> (because of missing/incompatible definitions), and IO is defined to
> match the behavior of the host, not target, platform (in the cross
> compiling case). The only interaction between the two phases is that
> quoted syntax is resolved against the the run-time phase's definitions
> (just like today).
> 
> Some of you may find this a shoddy substitute for defining a subset of
> Haskell which behaves identically on all platforms, and optionally
> constraining TH to it. But the big feature that my proposal offers and
> that one doesn't is to be able to independently specify compile-time
> dependencies for the host-oriented TH---this is analogous to the
> newish `Setup.hs` dependencies. That in turns leads to what I think is
> the "killer app" for Host-Oriented TH: exposing the various
> prepossessors we use (alex, happy, hsc2hs, even CPP) into libraries,
> and side-stepping any need for "executable dependencies" in Cabal.
> Note also that at least hsc2hs additionally requires host-IO---there
> may not even exist a C compiler on the target platform at all.
> 
> Finally, forgive me if this has been brought up before. I've been
> thinking about this a while, and did a final pass over the GHC wiki to
> make sure it wasn't already proposed, but I could have missed
> something (this is also my first post to the list).
> 
> John
> 
> [1]: https://github.com/ghcjs/ghcjs/blob/master/lib/ghcjs-prim/GHCJS/Prim/Internal/Build.hs