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 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 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...

---

ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Hello John, Almost! As you point out, if you just want a cross-compiler, you don't need to build stage2. The real problem is that we want stage0 to be *the same version* as stage1, so that stage0 has the correct API in order to load stage0 libraries which are going to be used for TH, plugins, etc. (Alternately, build a non-cross-compiler stage1, and then a cross-compiler stage2--NOT a cross compiled stage 2.) Edward Excerpts from Ericson, John's message of 2016-01-19 16:13:24 -0800:

From #11378:

...

Can we actually link against the old version of ghc? Yes we can! All we need is (1) for it to have been built with a different IPID, and (2) to use module renaming to rename the relevant modules to a different module name, so that we can import them without a conflict.

If I understand this, you are saying stage1 links stage0 (the normal, non-cross-compiler used to build stage1), to build stage2? I agree that should work, but if stage1 is multi-target isn't that level of complexity not even needed? I'm not too familiar with GHC or its build system, but a multi-target compiler that doesn't support normal TH doesn't seem that hard to build in principle.

John

On Tue, Jan 19, 2016 at 3:59 PM, Ericson, John wrote:

...

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 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 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...

---

ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs