[Haskell-cafe] Well typed OS

[Joachim Durchholz]

Am 08.10.2018 um 01:34 schrieb Vanessa McHale:
> The problem with an IR is that some languages would inevitably suffer - 
> LLVM in particular was designed as a backend for a C compiler, and so it 
> is not necessarily well-suited for lazy languages, immutable languages, 
> etc. (not to mention self-modifying assembly and other such pathological 
> beasts...)
Actually LLVM is built for being adaptable to different kinds of 
languages. It does have a bias towards C-style languages, but you can 
adapt what doesn't fit your needs *and still keep the rest*.

The following was true a few years ago:

When I asked, the LLVM IR was intentionally not specified to be reusable 
across languages, so that different compiler toolchain could adapt the 
IR to whatever needs their language or backend infrastructure needed.

Garbage collection is one area where you have to do a lot of work. There 
are some primitive instructions that support it, but the semantics is 
vague and doesn't cover all kinds of write barriers. You'll have to roll 
your own IR extensions - or maybe I didn't understand the primitives 
well enough to see how much they cover.
Anyway, LLVM does not come with a GC implementation.
OTOH, it does not prevent you from doing a GC. In particular, you're 
free to avoid C-style pointers, so you have the full range of GC 
algorithms available.

Laziness? No problem. If you do tagless/spineless, you'll code the 
evaluation machine anyway. Just add an IR instructions that calls the 
interpreter.

Immutability? No problem - actually nowhere a problem. Immutability 
happens at the language level, at the IR level it is pretty irrelevant 
because compilers try to replace object copying by in-place modification 
wherever possible, anyway.

Self-modifying assembly? No IR really supports that. Mostly it's 
backends that generate self-modifying code from IR instructions for 
specific backends.

TL;DR: For its generality, LLVM IR is better suited to languages with 
specific needs in the backend than anything else that I have seen (which 
means C runtimes, various VM proofs of concept which don't really count, 
and JVM - in particular I don't know how .net compares).

Regards,
Jo