PureScript Gerbil backend (PureScript->Gerbil transpiler)

[bjornkihlberg]

I wrote a Chez Scheme backend for PureScript a while back and it would not be a huge project for me to port it to Gerbil. I wanted to start a discussion here to lay out my thoughts of how this would work and get feedback on best practices in Gerbil.

What is PureScript?

PureScript is basically Haskell but built with dynamically typed languages as compilation targets (or "backends") in mind. The official backend is JavaScript.

When PureScript code is compiled it is compiled into an intermediary representation called CoreFn which is a JSON format. Each PureScript module (including external dependencies) will be compiled into a single CoreFn JSON file and put into an output folder.

Rough idea

So here's how I see a Gerbil backend would optimally work:

• ./src contains your Gerbil source code.
• ./ps_src contains your PureScript code and Gerbil source files that your PureScript code can import. For example, ./ps_src/MyLib.ps imports a procedure defined in ./ps_src/MyLib.ss.
• ./ps_output contains the CoreFn build artifacts that your Gerbil code in ./src may import and use

Compilation would mean that you first compile the PureScript source and then compile your main Gerbil program which, for optimal simplicity, can import the CoreFn files directly. Otherwise you would need to have a process that actually generates the Gerbil source files which is an extra step that would be nice if we can skip.

If this doesn't make much sense, some simple questions that when answered, would also answer what could be done to achieve a smooth and straight forward process for the programmer.

1. Could you automate building your PureScript source before your Gerbil source?
   Obviously. If Gerbil doesn't support build scripts you could always just implement a Makefile that automates this process.
2. Could you create an import form that can import the following JSON file as if it were a Gerbil source file...

   ["define", "f", ["lambda", ["x"], ["*", "x", "2"]]]

   ... and then invoke f? It looks like gerbil has procedural macros and modules so it should be possible to generate a module based on the contents of non-gerbil source files. Another possibility that I've heard mentioned is to define a custom language. As long as you don't have to manually insert a compiler directive into the CoreFn source files, it might be a viable solution. It looks like you can declare what language a source file is in gerbil.pkg. The issue with that is that PureScript tends to output a lot of build artifacts so it would not be fun for programmers to have to list them all in gerbil.pkg.

Some thoughts about Gerbil

I'm new to Gerbil and there are some things that I see which are really interesting with regard to this project.

One thing to remember about type classes is that they have dynamically dispatched methods which PureScript models by implicitly passing a lookup table to each procedure. As I understand it, Gerbil has a mechanism to avoid dynamic dispatch that I don't entirely understand but this could make Gerbil a very competitive backend for PureScript.

In Haskell and PureScript there is the notion of a newtype which is basically a type that obfuscates the underlying representation. For example you could define

newtype PhoneNumber = MakePhoneNumber String

f :: PhoneNumber -> ---
f phoneNumber = ---

which means that f can only be called with values that are of type PhoneNumber. You could not call f with values of type String. This should in theory have no runtime cost but there is a slight runtime cost when introducing a PhoneNumber value from a String. MakePhoneNumber :: String -> PhoneNumber is a generated function that is the identity function. As far as I can tell, Gerbil doesn't have variable transformers or identifier properties so you couldn't remove calls to MakePhoneNumber but keep references to MakePhoneNumber when it's not invoked.

Value proposition of a PureScript Gerbil backend

• PureScript is really nice. I used it together with Chez Scheme and it was very nice to be able to use either language in whichever regime it shines in.
• You get parts of the efforts of PureScript's ecosystem for the relatively low price of maintaining a project that shouldn't require a huge amount of effort. For example
  • Backend agnostic libraries developed by the PureScript community would work with Gerbil
  • IDE tooling developed by the PureScript community
• If this project is reliable and Gerbil is seen as a serious language by outsiders, it could attract some high quality developers to the Gerbil ecosystem in the long run.
• A notch on my CV.
• I will learn a lot of Gerbil by building this.