Viability of hxb based custom backends?

[back2dos]

I expect this to be way beyond any of the immediate plans for hxb, but:

If for a moment we assume the existence of haxe based hxb reader, I can see how using hxb to integrate custom backends would make sense, where the compiler dumps hxb for another process that does the actual code generation (ideally the compiler would spawn the generator and stream the target context hxb into its stdin).

One can of course get relatively far with just doing code generation in eval, however this approach has several advantages:

1. the overhead of the intermediary hxb step can be overcompensated for on runtimes with faster execution speed and true concurrency support
2. the target's "native" tooling could be integrated, e.g. a custom C# backend of this kind could be compiled to C# and then more easily integrate other .NET tools, e.g. use CodeDOM to bootstrap an IL target from there ... to overgeneralize completely: any language X with a bootstrapped compiler could in essence get Haxe integrated as a frontend via hxb, by writing a hxb -> X compiler in Haxe

There's nothing immediately actionable here (even a reader should wait for the format to stabilize), but I wanted to bring it up now, before any design decisions get frozen that might be too much of an obstacle. Perhaps @SomeRanDev has any comments based on his experience with custom backends?

[Simn]

I was thinking about that as well and I don't see any major obstacle here (other than performance problems like in #11487). I want to add format.hxb.Reader at some point, if for no other reason than making sure that we're not tunnel-visioning too much with the OCaml implementation.