Fwd: Fwd: Host-Oriented Template Haskell

[Ericson, John]

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 <ezyang at 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_ericson at 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 <ezyang at 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_ericson at brown.edu>
>> >>> Date: Tue, Jan 19, 2016 at 1:17 PM
>> >>> Subject: Host-Oriented Template Haskell
>> >>> To: Haskell-Cafe <haskell-cafe at 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 at haskell.org
>> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs