Has anyone taken a look at GRIN and had any thoughts with respect to its suitability as a PureScript backend?
From my brief look at the docs, it sounds if native machine code is the desire, it might be easier to compile to the GRIN intermediate language. GRIN, then, would compile to LLVM is similar to get to machine code.
I’m not sure how FFI would work, but it looks like they have thought about it and maybe have a POC of it. Perhaps the constraint on FFI would be that LLVM would need to support the FFI language?
My admittedly limited exposure to whole program optimization has essentially only given me the impression that it’s ridiculously slow. These are impressions from reading about MLton (ML) and Stalin (Scheme). Given that backdrop (which as far as I know is the default in those circles) I would’ve expected any improvements in that regard to be mentioned in the promo bits, but it doesn’t seem to be there.
With that in mind I think it could be easy to make compilation of PureScript prohibitively slow by running it through a whole program optimizing compiler. ML in general lends itself to fast compilation but they even managed to make that slow.
It’s definitely really cool, though, and I really like the idea of getting a sort of re-targeting for free with it.
Edit: I guess in the end it’s really only an issue of someone / people doing it if they really like the idea and yay, benefit for everyone, as long as it doesn’t disrupt the core.
Edit 2: I guess I should revise this because obviously as long as there’s parity, development can be done with fast compilers and releases built with slower ones, so I’m not sure what I said is valid.
One interesting point: that one of the values/principles of PureScript is that the generated code is readable, for some definition of readable. This implies that any backend that PureScript supports should be a human-readable language. If the GRIN IL is not a human-readable language, then, any changes to the core compiler to support that backend is liable to rejection. If no changes to core is required, then GRIN might be a good “build for production” backend for PureScript.
This looks very interesting. It sounds like there’s a good chance that going from corefn->grin is doable. I think it would be really cool if we could get programs with great performance without having to implement a proper optimizer in the main compiler.
GRIN is very interesting, but we’re not going to get great performance without doing specialization, which GRIN basically can’t do as it needs to happen before we elaborate typeclasses into dictionary passing. I also don’t think it ships with a garbage collector, so we’d need to add that as well as an efficient RTS implementation of Hashmaps to get reasonable perfomance for our records. (I have a feeling beating V8 is going to be very tricky :D)
