Grain lang announcement: possible compiler target?

Feedback
, ,
#1

Hi PureScripters!

tl;dr: Compiling to WASM could become much easier by compiling to Grain

So far I have not seen this come up here but I think Grain Lang announcement is quite huge for functional programming in the browser (and beyond!). It’s a relatively low level functional programming language compiling to to Webassembly (WASM). Furthermore they seem to have plans for a DOM standard library (or bridge).

I am not a specialist for compilers or WASM but I think this is very exciting for the following reasons: Many might want to argue that performance is not a huge factor for large scale real world adoption. But I think it is always a negative (cons) point for PureScript. If there was a CLang equivalent for functional languages I think this would be huge and Grain could be this for the browser (and Mozilla also has big plans for web-assembly outside of the browser). I think Haskell also compiles to some in-between-language inspired by lambda calculus. If these low level performance optimisation is done by another compiler, PureScript could benefit hugely from it. The DOM bridge of Grain is also very interesting. Currently, to interact with browser APIs, WASM needs to interface back with JS APIs. This makes compiling to WASM unattractive since one also has to maintain all the bridge code. This could also be done by Grain. Lastly Mozilla is working on WASM interface types. WASM modules can interface with other WASM modules compiled from other languages. Concretely PureScript could gain access to a rich FFI to basically any language that compiles to WASM. Making PureScript a viable choice for server side development.

All of this obviously assumes that there is a performance benefit gained from compiling to Grain. Would love to hear your thoughts on Grain and maybe hear about what you think Grain would have to introduce for it to become a possible compiler target. (e.g. type classes would be a huge addition that Grain has no equivalent for)

5 Likes
#2

If targeting Grain, wouldn’t we still need to maintain bridge code to Grain’s DOM library?

Language-wise, is Grain essentially ReasonML with WASM output?

It looks like this is the pathway from .gr files to WASM:
.gr --> Grain --> Binaryen --> WASM

Here’s a similar strategy for .hs input:
.hs --> Asterius --> Binaryen --> WASM

2 Likes
#3

Like with any other compiler target, I think it would need it’s own FFI implementations. The language does indeed look a bit like ReasonML. I am not sure if they want to add more language features and even see themselves as a compiler target. And you are right, one could instead target Haskell (which might be easier since Haskell and PS are 90% the same). I think the point I am trying to make is that creating a similar project like Asterius for PureScript could be much easier by going via Grain (especially since PureScript doesn’t target machine code in the first place).

#4

I know this is the wrong answer for this forum, but why not just use Grain directly if performance is your greatest concern? The easiest route to high performance would simply to use PureScript and Grain together, maybe with a generated bridge to call each from either direction