Oops, Sent just to Edward by mistake. ----
That all sounds good to me---I think what I was thinking all along in fact, unless I am still missing some nuance :). My idea of using a multi-target compiler was to avoid needing stage0 to be the same version as stage1 (or adding a new stage, stage1 as in your alternative). The cross compiler is multi-target so it doesn't need to link another compiler to load plugins / run "host-oriented Template Haskell". I mentioned the usecase of trying to build a stage2 which needs plugins / Host-Oriented Template Haskell, but it could well apply to building anything else with the need for those to things (and not normal TH, which cannot be built with a cross compiler) In diagrams, rather than: > stage0 (version foo, platform-x -> platform-x) > ==> stage1 (version foo, platform-x -> platform-y) > ==> some program (with plugins, with host-oriented TH, without normal TH) or > stage0 (version bar, platform-x -> platform-x) > ==> stage1 (version foo, platform-x -> platform-x) -> > ==> stage2 (version foo, platform-x -> platform-y) -> > ==> some program (with plugins, with host-oriented TH, without normal TH) do just > stage0 (version bar, platform-x -> platform-x) > ==> stage1 (version foo, platform-x -> {platform-x, platform-y}) > ==> some program (with plugins, with host-oriented TH, without normal TH) Now it may be that building such a multi-target compiler today is just as arduous as making sure one has a native compiler of the same version before building the cross compiler, so my idea is of no practical value. But if so, I hope in the long term that could be fixed. John On Wed, Jan 20, 2016 at 8:37 PM, Edward Z. Yang <ezy...@mit.edu> wrote: > 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 <john_eric...@brown.edu> >> 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 <ezy...@mit.edu> 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 <john_eric...@brown.edu> >> >>> Date: Tue, Jan 19, 2016 at 1:17 PM >> >>> Subject: Host-Oriented Template Haskell >> >>> To: Haskell-Cafe <haskell-c...@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 >> >> _______________________________________________ >> >> ghc-devs mailing list >> >> ghc-devs@haskell.org >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs