Fwd: Host-Oriented Template Haskell

[Ericson, John]

>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