PureScript is a small strongly typed programming language with expressive types, written in and inspired by Haskell; purerl is a PureScript backend targetting Erlang source.

• PureScript discord channel #purerl - general discussion, support, news
• purerl API docs - API docs generated from the latest package set
  • purerl Pursuit - a version of the PureScript pursuit documentation repository for purerl package sets (no longer being kept up to date)
• The purerl organisation hosts ports of some core libraries.
• The purerl-cookbook contains some code examples and explanations.
• The purerl-optimiser which memoizes type class dictionaries

Currently the purerl executable should correspond to purs compiler versions as follows:

Binaries are available for download on the github releases.

A nix overlay is also available at nixpkgs-purerl, with related packages available at nixpkgs-purerl-support (or easy-purescript-nix).

The purerl backend requires the mainline PureScript compiler (purs) to operate. It generates .erl source files from the CoreFn purs compiler output (and externs.json type information), which can then be compiled by erlc.

The recommended usage is with spago, which now supports alternative backends. In spago.dhall set

{ name = "my-project",
, backend = "purerl"
, ...
}

and in packages.dhall include a purerl-specific package set, e.g.

let upstream =
      https://github.com/purerl/package-sets/releases/download/erl-0.14.4-20211012-1/packages.dhall

Then

• spago build will build the project through to .erl
• spago run will run the project from a given entry point

First compile to the CoreFn representation, e.g.

• purs compile 'my_deps/**/*.purs' 'src/**/*.purs' --codegen corefn
• pulp build -- --codegen corefn
• psc-package build -- --codegen corefn

Then run purerl to generate .erl files

• purerl

(No parameters are required, purerl will build whatever is in output/).

The standard PureScript IDE tooling based on purs ide and editor plugins and/or PureScript Language Server should work with purerl projects, but should be configured to generate corefn rather than js, eg with vscode:

"purescript.codegenTargets": [ "corefn" ]

The compiler knows of primitive types and the corresponding Erlang types, and some others for codegen optimisations, some other library types are included here for reference.

Top level declarations are uniformly output as nullary functions, where arguments are curried as in the PureScript types. Identifiers are preserved, with quoting if required. Thus a normal invocation of the output will look like (main@ps:main())(). An uncurried version is also provided (and used in generated code), see below.

There is special handling of values of the following types at the top level:

• Data.Function.Uncurried.FnX
• Data.Function.Uncurried.EffectFnX

These will generate code as for an X arity function, i.e. an arity X overload will be generated directly, being suitable for usage in callback module implementations, allowing for code replacement, etc.

Module names Foo.Bar are transformed to a lower-snake cased form foo_bar (any non-initial uppercase chars will be preserved as such), with a suffix @ps to avoid clashing with built-in erlang modules.

In place of .js FFI files, the Erlang backend has .erl FFI files. As per the regular compiler since 0.9, these must be placed along the corresponding .purs file with the same name.

Module name: Foo.MyModule PureScript file Foo/MyModule.purs Erlang file: Foo/MyModule.erl Erlang module: foo_myModule@foreign

Note that the FFI code for a module must not only be in a file named correctly, but the module must be named the same as the output module with @foreign appended (so not following the Erlang module naming requirement until this gets copied to output).

FFI files MUST export explicitly the exact set of identifiers which will be imported by the corresponding PureScript file. The compiler will check these exports and use them to inform codegen.

Auto-currying: functions can be defined with any arity. According to the arity of the export (parsed from the export list) the compiler will automatically apply to the right number of arguments. By extension, values are exported as a function of arity 0 returning that value.

An example:

module Foo.Bar where

foreign import f :: Int -> Int -> Int -> Int

-module(foo_bar@foreign).
-export([f/3]).

f(X, Y, Z) -> X + Y * Z.

This could also have been defined as

-module(foo_bar@foreign).
-export([f/1]).

f(X) ->
  fun (Y) ->
    fun (Z) ->
      X + Y * Z
    end
  end.

Following the module name mangling and representation above, calling a purerl function defined as follows

module Foo.Bar where

import Prelude

appendNumber :: String -> Int -> String
appendNumber str n = str <> show n

goes something like this:

-module(my_module).

f() -> ((foo_bar@ps:appendNumber())(<<"hello">>))(42).

Note that foo_bar@ps:appendNumber() represents the function value, and we call that like a chain of arity-1 erlang functions as according to the number of curried arguments. Parentheses soon stack up due to erlang precendence. Fortunately, an uncurried overload is generated:

-module(my_module).

f() -> foo_bar@ps:appendNumber(<<"hello">>, 42).

These overloads should be generated at least for exported functions.

Note that functions with type class constraints should not be called from outside of PureScript, similar to the guidelines for FFI functions.

Several .hrl files are generated in output, with the intention of improving dialyzer analysis. For a module Foo.Bar

• foo_bar.hrl - All types used in the module, this is imported by [email protected] and foo_bar@ps
• [email protected] - Types of the foreign imports of the module - note that currently these are only able to be generated when the imports are exported by the PureScript module

You may wish to import [email protected] in your FFI file in order to check the types of your imports, though bear in mind the .erl file will be copied from the source to output/ - either some creative library paths or copying of the generated hrl will be required.