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
<john.ericson@obsidian.systems> 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 <ghc-devs-boun...@haskell.org>
<mailto:ghc-devs-boun...@haskell.org> *On Behalf Of *Csaba Hruska
*Sent:* 10 April 2021 11:49
*To:* GHC developers <ghc-devs@haskell.org>
<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>
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
