Ah thanks for the link. Template Haskell with only {-# TH-ONLY #-}
imports is precisely equivalent to what I propose. I find a clean
separation with that and normal TH useful, however, precisely so the
stage2 compiler's source can include such a thing.On Tue, Jan 19, 2016 at 3:20 PM, Edward Z. Yang <[email protected]> wrote: > 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 <[email protected]> >> Date: Tue, Jan 19, 2016 at 1:17 PM >> Subject: Host-Oriented Template Haskell >> To: Haskell-Cafe <[email protected]> >> >> >> 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 > _______________________________________________ > ghc-devs mailing list > [email protected] > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
