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
Date: Tue, Jan 19, 2016 at 1:17 PM
Subject: Host-Oriented Template Haskell
To: Haskell-Cafe
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/Interna...
