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 <[email protected]> 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 <[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
