Indeed it is! I also am very much hoping this can be the missing piece we need to allow Template Haskell to work with a stage 0 GHC, so that we can safely use TH in GHC itself even when the ABI is changing. See https://github.com/ghc-proposals/ghc-proposals/issues/162 for details, where I've also linked Csaba's blog post. (And maybe also https://gitlab.haskell.org/ghc/ghc/-/wikis/cross-compilation/roadmap for more background, and related things like https://github.com/ghc-proposals/ghc-proposals/pull/412.) TH could perhaps be used to replace some of the ad-hoc code gen we have for e.g. RTS constants and primops. This in turn would simplify the build system, allowing for `cabal install ghc` to work without shipping generated Haskell code in the sdist. John On 4/12/21 4:51 AM, Simon Peyton Jones via ghc-devs wrote:

That’s extremely impressive, Csaba.

Maybe of interest to folk who have been thinking about “fat interface files”.

Simon

*From:*ghc-devs *On Behalf Of *Csaba Hruska *Sent:* 10 April 2021 11:49 *To:* GHC developers *Subject:* External STG Interpreter blog post

Hello,

I've written a blog post about GHC-WPC's external stg interpreter. https://www.patreon.com/posts/external-stg-49857800 https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fposts%2Fexternal-stg-49857800&data=04%7C01%7Csimonpj%40microsoft.com%7C1535f88608f549dabb8108d8fc0e4c3f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637536486264337310%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=VXa%2FhDs1ePRS5NTu04buv42yj%2BFKw%2FJzBLQJSwp8qTs%3D&reserved=0

Feedback is welcome.

Cheers,

Csaba

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

Hi Csaba, Thanks for your interest. I'm not sure whether it would be better to do a call sooner or later, but certainly want to get to this at some point. Fendor and Sylvain (and occasionally I too) have been chipping away at multiple home packages, which I hope could help with these sorts of whole program things. I'm sort of thinking milestones like: 1. Proper Int64 => Single sdist for GHC the library that is truely target/configures-script-choice agnostic, but sdist contains vendored generated code 2. Multiple home packages => Maybe easier to rig up what you have with GHC's driver, though I suppose not needed for Hadrian since it uses one-shot mode. 3. Extensible interface directory => Can better upstream your work to save STG for later, needed for Hadrian / one-shot mode. 4. Matthew's proposal => can get whole program closure for just for TH, pruning away runtime stuff. 5. Put it all together => single sdist that is much more minimally processed, with TH instead of including generated code (no vendoring or Setup.hs evils necessary). Easier to work on IDE stuff with either sdist or fresh checkout of GHC. So it's quite a while before GHC is ready to fully leverage your work on the TH front, I think, but we could still talk through things in advance of that if people are interested. Also, included Sylvain Henry in the thread who's now back from paternity leave, John On 4/20/21 5:38 PM, Csaba Hruska wrote:

Hello,

In theory the ext-stg interpereter could be used to run TH, but it is not done yet. I'm interested in optimization much much more, but I deliberately designed the ext-stg ir/tooling to be simple and easy to use and understand for others so that an average Haskell programmer could implement his ideas or do his experiment. I'm also open for discussion about the possibilities. We can have a video meeting about this if you'd like to.

Cheers, Csaba

On Mon, Apr 12, 2021 at 7:57 PM John Ericson wrote:

Indeed it is!

I also am very much hoping this can be the missing piece we need to allow Template Haskell to work with a stage 0 GHC, so that we can safely use TH in GHC itself even when the ABI is changing. See https://github.com/ghc-proposals/ghc-proposals/issues/162 https://github.com/ghc-proposals/ghc-proposals/issues/162 for details, where I've also linked Csaba's blog post. (And maybe also https://gitlab.haskell.org/ghc/ghc/-/wikis/cross-compilation/roadmap https://gitlab.haskell.org/ghc/ghc/-/wikis/cross-compilation/roadmap for more background, and related things like https://github.com/ghc-proposals/ghc-proposals/pull/412 https://github.com/ghc-proposals/ghc-proposals/pull/412.)

TH could perhaps be used to replace some of the ad-hoc code gen we have for e.g. RTS constants and primops. This in turn would simplify the build system, allowing for `cabal install ghc` to work without shipping generated Haskell code in the sdist.

John

On 4/12/21 4:51 AM, Simon Peyton Jones via ghc-devs wrote:

...

That’s extremely impressive, Csaba.

Maybe of interest to folk who have been thinking about “fat interface files”.

Simon

*From:*ghc-devs mailto:ghc-devs-bounces@haskell.org *On Behalf Of *Csaba Hruska *Sent:* 10 April 2021 11:49 *To:* GHC developers mailto:ghc-devs@haskell.org *Subject:* External STG Interpreter blog post

Hello,

I've written a blog post about GHC-WPC's external stg interpreter. https://www.patreon.com/posts/external-stg-49857800 https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fposts%2Fexternal-stg-49857800&data=04%7C01%7Csimonpj%40microsoft.com%7C1535f88608f549dabb8108d8fc0e4c3f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637536486264337310%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=VXa%2FhDs1ePRS5NTu04buv42yj%2BFKw%2FJzBLQJSwp8qTs%3D&reserved=0

Feedback is welcome.

Cheers,

Csaba

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