GRIN and the GHC RTS

[dmjio]

Hey Lennart, was curious to know your thoughts on these topics in general, and their possible inclusion into MicroHs.

GRIN

Was curious your thoughts on using first order GRIN as an IR (as seen in JHC, etc) to the MicroHs project (for something like -wpo mode). And importantly, do you think GRIN is a viable / practical IR for larger Haskell projects?

• Possible Benefits:

  • Smaller executables
  • Removal of indirect calls
  • Explicit laziness being inlined (eval inlining)
  • Fewer allocations
  • Simpler than STG

• Possible Downsides:

  • Potentially long compilation times (analysis other than Steensgaard + finding a fixed point during optimization might take a very long time).

GHC RTS

• Would you consider implementing some of the GHC RTS features (threading, concurrency primitives, etc.) within MicroHs?
• Could a standalone C implementation (divorced from STG) of the RTS be possible for MicroHs?

Thanks !

[augustss]

I don't know how well GRIN works on a larger scale. I always thought that GRIN compilation should support a mix, so whole program compilation would not be necessary. I told Urban (Boquist) this when he was doing his thesis, but he never got to that point.

If someone wants to do GRIN for MicroHs, so much the better. I think it could be a fun project.
I don't think the executables would be any smaller than currently; the combinator code is quite compact.

I am thinking about how to support threading in MicroHs. It will require a substantial rewrite of the combinator interpreter so it no longer uses the C stack. But that's a good thing to do, so I expect I'll get there in a while.
I want to be able to run MicroHs on micro-controllers, and most applications really need concurrency there.

I'm not sure what you mean by "a standalone C implementation of the RTS". Do you mean based on the GHC RTS?

[dmjio]

Yes, I think it would be nice to have the concurrency portion of the GHC RTS made a library (similar to what OCaml has with lwt), so it could be used by other Haskell compilers. Right now the GHC RTS threads implementation seems very specific to the STG machine, and it has to be included in all programs as well.

Going a step further, I think it would be nice to not have a runtime at all for Haskell programs (this is kind of a goal of jhc as well). Since GRIN generates eval and inlines it into every program that is a big step forward. If concurrency could be made a library then it seems all we'd need is a GC included. For compiling to JS the GC could even be omitted. Maybe this approach could have merit for micro-controllers too.

[augustss]

I think disentangling the concurrency part of the GHC RTS is a major undertaking. I was not designed with that in mind.

I do think a Haskell implementation with only GC in the runtime is doable. The MicroHs RTS does not have much in it, apart from eval.

[dmjio]

To follow up on this, @csabahruska has done some work on disentangling the RTS (has scheduler and concurrency primitives implemented (STM, MutVar, etc) - most GHC tests are passing) in his external-stg-interpreter project.

One idea could be to extend MicroHs with staging and then port a staged implementation of the GHC RTS (from the external-stg-interpreter above) to MicroHs. Staging might allow the Haskell RTS implementation (from the external-stg-interpreter) to be compiled alongside each application, making the RTS subject to MicroHs's optimizer as well.