Interesting but probably out-of-scope idea: Use copy-and-patch compilation

[sgraf812]

From what I get, MicroHs uses bracket abstraction to break down Haskell into supercombinators.
The language of supercombinators can be seen as a form of parameterless bytecode IR; this IR is then interpreted in eval.c.

For nothing else than fun and profit (and for what else is this project :)), you could consider, instead of interpreting this bytecode, to compile it just in time.

This process can be done really fast, and yield quite fast code as well, if you precompile your supercombinators into a library of stencils at bootstrap time and then just copy/mmap them together for the particular bytecode IR at compiler run-time. Of course, these stencils will in general have holes in them for register/stack operands and constants which need to be patched-in by the compiler. This is the basis of copy-and-patch compilation, a work which you might enjoy. Python 3.13 recently shipped with such a JIT.

There apparently is a C++ library called MetaVar to generate and do AST pattern-matching for stencils using Clang and its GHC calling convention (which is attractive because MetaVar compiles stencils to CPS), but I haven't found it so far after a bit of Googling. This is probably a no-go for the stated objectives of your project anyway, since that is quite a heavy dependency footprint. Nevertheless, I thought you might find this avenue interesting.

[augustss]

I have indeed thought of some kind of JIT, which would treat a function body as a super-combinator and generate code for it. But you can do substantially better than copying a body for each of the combinators, and instead generate code that avoids a lot of the overhead associated with combinators.
Indeed, the very first functional language compiler I wrote (in 1981) used template copying, where there was a template for each super-combinator. The code did a memcpy of the template and then patched the wholes. So I'm familiar with the idea. :)
We will see where things go. I have many things on my TODO list.

Nitpick: MicroHs compiles to a fixed set of combinators, so it's not really what traditionally is called supercombinators.

[augustss]

I read the paper you linked to. That's a very interesting approach. I will keep that in mind if I ever decide to do a JIT. Thanks!