On macOS High Sierra,

$ make examples
[...]
usage:  ar -d [-TLsv] archive file ...
	ar -m [-TLsv] archive file ...
	ar -m [-abiTLsv] position archive file ...
	ar -p [-TLsv] archive [file ...]
	ar -q [-cTLsv] archive file ...
	ar -r [-cuTLsv] archive file ...
	ar -r [-abciuTLsv] position archive file ...
	ar -t [-TLsv] archive [file ...]
	ar -x [-ouTLsv] archive [file ...]
make[3]: *** [libpurec.a] Error 1
make[2]: *** [../../libpurec.a] Error 2
make[1]: *** [main] Error 2
make: *** [examples] Error 2

Required by #12

Seemingly popular options I've found:

• ccan's darray (header-only) - https://github.com/rustyrussell/ccan/blob/master/ccan/darray/darray.h
• vec - https://github.com/rxi/vec

Will probably go ahead with any of them as replacing them should be trivial.

Also see #12

We vendored the tests that come with the purescript compiler (for now). These tests are discovered, built, and executed in https://github.com/pure-c/pure-c/blob/c578687bff74370b92bdf95976b38c8adcc7b10d/test/Main.purs#L31-L59.

All tests use this makefile that is generated exactly once per pulp test:

https://github.com/pure-c/pure-c/blob/c578687bff74370b92bdf95976b38c8adcc7b10d/test/Main.purs#L61-L83

This means that all tests share the same build directory and thus can re-use shared build artifacts. Hence, the first build to run will take the longest, has it has to build a lot of the dependencies that are required. This will usually time out.

Instead, we should create a dummy target (or choose a test we consider infallible) that is built prior the actual tests running.

purescript-c/purescript-effect

• Effect.bindE
• Effect.pureE
• Effect.untilE
• Effect.whileE
• Effect.forE
• Effect.foreachE
• Effect.Uncurried.*
• Effect.Unsafe

Required by #12

Implement something akin to:

https://github.com/purescript/purescript/blob/a8e0911222f46411776978a13866eb097175162c/src/Language/PureScript/CoreImp/Optimizer/Inliner.hs#L83-L107

We could further modify the AST to unbox values based on the operation being taken (thus erasing the intermediate purs_any_t altogether for e.g. addition etc.).

https://github.com/purescript/purescript/blob/b07042fb7b4f6a68c0fdc68b7e51076b7106cfba/src/Language/PureScript/CoreImp/Optimizer/Blocks.hs

Depends at least on #12, #10. This is a distant goal.

Current traversals are a straight adaption from the PureScript codebase. This implemention will suffice while building out the actual optimization passes, but should be re-implemented in a stack-safe manner for real world usage.

https://github.com/pure-c/pure-c/blob/19298afaaa1096fc37ab3a37d57f69d9f326fb00/src/Language/PureScript/CodeGen/C/AST.purs#L250-L298

PureScript test "passing/1991.purs" is not passing because the currently generated C code redefines local variables (#12)

Without the inlineVariables optimization pass in the PureScript JS codegen, it spits out code looking similar to this:

var foldMap = function ($copy_dictSemigroup) {
    return function ($copy_f) {
        return function ($copy_v) {
            var $tco_var_dictSemigroup = $copy_dictSemigroup;
            var $tco_var_f = $copy_f;
            var $tco_done = false;
            var $tco_result;
            function $tco_loop(dictSemigroup, f, v) {
                var $2 = f;
                var $3 = v;
                var f1 = $2;
                if ($3.length === 5) {
                    var $4 = $3[0];
                    var a = $4;
                    var $5 = $3[1];
                    var b = $5;
                    var $6 = $3[2];
                    var c = $6;
                    var $7 = $3[3];
                    var d = $7;
                    var $8 = $3[4];
                    var e = $8;
                    $tco_done = true;
                    return Data_Semigroup.append(dictSemigroup)(f1(a))(Data_Semigroup.append(dictSemigroup)(f1(b))(Data_Semigroup.append(dictSemigroup)(f1(c))(Data_Semigroup.append(dictSemigroup)(f1(d))(f1(e)))));
                };
                var f1 = $2;
                var xs = $3;
                $tco_var_dictSemigroup = dictSemigroup;
                $tco_var_f = f1;
                $copy_v = xs;
                return;
            };
            while (!$tco_done) {
                $tco_result = $tco_loop($tco_var_dictSemigroup, $tco_var_f, $copy_v);
            };
            return $tco_result;
        };
    };
};

JavaScript doesn't care that e.g. f1 gets redefined at will, but we're not so fortunate in C. I think we should be able to generate unoptimized code that still compiles. We could forward declare variable introductions on a per-block level and then assign to them later. This rewrite pass would run on the initially generated AST.

WebAssembly seems like one obvious use case of this project so I was surprised that there wasn't any discussion about this here already. Forgive me if I'm overlooking something that already exists.

I'm wondering whether you've given this much thought or tried it out, and what challenges/limitations you've encountered or foresee.

Update the mk/target.mk file to have a one-to-one mapping from corefn.json to a .c file, something like: %.c: %/corefn.json. That means Make can compile the corefn jsons into C files in parallel using its' -j flag.

Fork: https://github.com/purescript-c/purescript-prelude
Modules:

• Prelude
• Control.Applicative
• Control.Apply
• Control.Bind
• Control.Category
• Control.Monad
• Control.Semigroupoid
• Data.Boolean
• Data.BooleanAlgebra
• Data.Bounded (incl. FFI)
• Data.CommutativeRing
• Data.DivisionRing
• Data.Eq (incl. FFI)
• Data.EuclideanRing (incl. FFI)
• Data.Field
• Data.Function
• Data.Functor (incl. FFI)
• Data.HeytingAlgebra (incl. FFI)
• Data.Monoid
• Data.NaturalTransformation
• Data.Ord (incl. FFI)
• Data.Ordering
• Data.Ring (incl. FFI)
• Data.Semigroup (incl. FFI)
• Data.Semiring (incl. FFI)
• Data.Show (incl. FFI)
• Data.Symbol (incl. FFI)
• Data.Unit (incl. FFI)
• Data.Void
• Data.Monoid.Additive
• Data.Monoid.Conj
• Data.Monoid.Disj
• Data.Monoid.Dual
• Data.Monoid.Endo
• Data.Monoid.Multiplicative
• Data.Ord.Unsafe (incl. FFI)
• Data.Semigroup.First
• Data.Semigroup.Last
• Data.Record.Unsafe (incl. FFI)
• Type.Data.Row
• Type.Data.RowList

When compiling a project, also generate a Makefile that essentially replaces this part:

https://github.com/felixSchl/purescript-c/blob/master/Makefile#L28-L35

with something dynamic.

Either:

• mandate this for all main functions,
• or detect at compile time based on the type of main (if that information is even available),
• or by checking the return value at runtime: if NULL (implying Unit), return 0, else return purs_any_get_int(...) of result.

Required by #12

when I compile pure-c/purescript-arrays#1 test file cause an RangeError

https://github.com/pure-c/purescript-arrays/blob/master/test/Test/Data/Array.purs

It would be preferable if the files could be copied as part of purs compile so that we can have incremental rebuilds of single modules. Currently the only way to invalidate a module is by producing a modified corefn.

Clang appears to choke on compiling the generated code for Data.Either.Nested. It uses all of my system's memory until I have to manually interrupt it to give up. The generated c code is about 3692 loc but that's pre macro expansion. I am not sure how to diagnose this further at this point.

Experimental: Implement reference counting as an alternative or as a complement to GC.

• Add a refcount int to purs_any_t
• Add a retain function to increment refcount (we can worry about atomicity later)
• Add a release function decrement the refcount
  • If refcount drops to zero clean up the contained purs_value_t, and free the pointer
• Update purs_vec_t to properly increment/decrement the reference count
• Update purs_record_t to properly increment/decrement the reference count
• Keep retain-ed references in scope structs
• Keep retain-ed references in _FFI scopes (and release after BODY)
• Emit release calls for allocated resources before returning from functions

What could be a nice workflow for users wanting to use purec? Install the purec utility from npm and somehow combine pulp with purec (maybe using pulp --then?). That would buy users file watching for free (although it wouldn't pick up on .c and .h files). We need to figure out how to generate the Makefiles and how to bring in the runtime (#13).

Currently the compilation goes from some sources into purs -g corefn -o <output-dir>, which will spit them into <output-dir>. We then iterate over the corefn.json files found in <output-dir>, but those files give no hint back to where they originated from, making it necessary to remember their origin somehow.

Required by #12

When looking into #40, I discovered this:

    const purs_any_t * b$$$ =
      NULL;;
    b$$$ =
      ({
        const purs_any_t * * $ivalue =
          purs_indirect_value_new();;
        const purs_any_t * $value =
          NULL;;
        purs_indirect_value_assign(
          $ivalue,
          $value
        );
        $value;
      });
    b$$$ =
      ({
        const purs_any_t * * $ivalue =
          purs_indirect_value_new();;
        const purs_any_t * $value =
          NULL;;
        purs_indirect_value_assign(
          $ivalue,
          $value
        );
        $value;
      });
    b$$$ =
      ({
        const purs_any_t * * $ivalue =
          purs_indirect_value_new();;
        const purs_any_t * $value =
          NULL;;
        purs_indirect_value_assign(
          $ivalue,
          $value
        );
        $value;
      });
    b$$$ =
      ({
        const purs_any_t * * $ivalue =
          purs_indirect_value_new();;
        const purs_any_t * $value =
          NULL;;
        purs_indirect_value_assign(
          $ivalue,
          $value
        );
        $value;
      });

Firstly, why is b'' ("b$$$") re-assigned over and over again and secondly, what is going on with the indirect variables here?

This does not appear to break anything, but is messy, causes unnecessary heap allocations, and should be removed.

https://github.com/purescript/purescript/blob/master/src/Language/PureScript/CoreImp/Optimizer/Unused.hs

Relates to: #3

Create a command line utility, perhaps named "purs-c" that transparently compiles the given input files to corefn and subsequently compiles those into C code.

Required by #12

Currently, during lambda erasure, continuations will capture everything that was introduced up to that point, regardless of whether the continuation will make use of it or not. We should instead analyze what bindings the continuation actually makes use of and only capture those.

https://github.com/pure-c/pure-c/blob/955df0c796d94dd4da91019db7ae4e7770c1fe5e/src/Language/PureScript/CodeGen/C.purs#L950-L958

Required by #12

Currently compiling Data.Either.Nested takes about 10 seconds. It emits about 84k lines of code! So we should (a) investigate optimization passes to remove the lines to output and (b) make it run fast even when generating large files like that.

Currently we rely on a clang extension called "Blocks" contributed to the compiler project by Apple that essentially gives us closures in C. It would be interesting to see if we can go without this extension in order to be able to compile without clang and to avoid the blocks runtime.

It should be possible to - at compile time - inspect each function's scope, create a struct for it, and model
functions like this:

f x =
  let r y =
   in x

typedef (const purs_any_t *) (* purs_fun_fn) (const void * ctx, const purs_any_t * arg);
typedef struct purs_fun {
  const void * ctx;
  purs_fun_fn fn;
} purs_fun_t;
typedef struct f_ctx { /* empty */ } f_ctx_t; // just NULL?
typedef struct f_r_ctx { const purs_any_t * x } f_r_ctx_t;
purs_any_t * f (const void * ctx, const purs_any_t * x) {
  const f_ctx_t * f_ctx = (const f_ctx_t *) f_ctx;
  purs_any_t * out = GC_NEW(purs_any_t);
  purs_fun_t * fun = GC_NEW(purs_fun_t);
  f_r_ctx * f_r_ctx = GC_NEW(f_r_ctx);
  f_r_ctx->x = x;
  fun->fn = f_r;
  fun->ctx = f_r_ctx;
  out->tag = FUNCTION;
  out->value.fn = fun;
  return (const purs_any_t *) out;
}

This should be a straightforward port of the equivalent Haskell code: https://github.com/purescript/purescript/blob/master/src/Language/PureScript/CoreImp/Optimizer/TCO.hs

Heap allocating boxes for integers, doubles, and chars seems very redundant when it should be cheaper to just copy around the box itself. This needs to be properly investigated.

I just found myself writing this FFI code:

PURS_FFI_FUNC_4(Control_Monad_ST_Internal_for, _lo, _hi, f, _, {
	int lo = purs_any_get_int(_lo);
	int hi = purs_any_get_int(_hi);
	for (int i = 0; i < hi; i++) {
		purs_any_app(purs_any_app(f, purs_any_int_new(i) /* ouch! */), NULL)
	}
	return NULL;
});

example repo is https://github.com/Lupino/pure-c-compile-able-library

https://github.com/purescript/purescript/blob/b07042fb7b4f6a68c0fdc68b7e51076b7106cfba/src/Language/PureScript/CoreImp/Optimizer/MagicDo.hs

Emit code for record updates etc., using the purs_record_ family of functions.

The current dictionary-based approach has poor performance because the dictionaries are frequently allocated and released, meaning that strings (keys) are frequently allocated and released as well. Considering that the dictionary is completely known a priori we might as well emit matching structs or use some purs_any_t ** and access them by some known pointer offset by key.

Branch bug/clang-opts demonstrates a minimal program to reproduce GC issues due to compile time optimization (any level of optimization appears to trigger this). Note that the various random seeming pure units need to be there to trigger the issue. I have a hunch it's related to type-classes (or hash maps, more generally speaking) - hence the monomorphic versions of bind, pure, and discard for Effect.)

For example, on my machine the example program prints: "test: append" as opposed to "test: quark", for example when compiled with -O3.

https://github.com/pure-c/pure-c/blob/c578687bff74370b92bdf95976b38c8adcc7b10d/src/Language/PureScript/CodeGen/C/Transforms.purs#L115-L135

Implement a decent set of packages to make pure-c as a language more useful.

I think a good candidate list could be what is required to make #12 happen:

#12 (comment)

Tracked issues:

• purescript-effect #11

All of these tests should eventually pass using this backend: https://github.com/purescript/purescript/tree/master/tests/purs/passing.

The directory structure is set up such that every (NAME).purs file is a test with additional supporting modules optionally residing in a folder named (NAME)/ in the same directory.

The logic for this already exists for the most part: https://github.com/felixSchl/purescript-c/blob/5ccdd0584d856584259096eadd11d316375f476d/test/Main.purs#L49-L57.

• Resolve dependencies (do all tests just rely on prelude?)
• Compile Makefiles (#13)
• Generate test suite using purescript-spec (each test case should become an it block)

The current output is heavily based on expressions, meaning that we apply functions and feed the result into other functions etc. It would be interesting to explore a transform that would turn these expressions into statements by generating fresh variable names in the current block scope and then perform the wiring up.

For example:

Turn this:

purs_any_app(f, purs_any_app(g, purs_any_int_new(100)))

into this:

const ANY * $value0 = purs_any_int_new(100);
const ANY * $value1 = purs_any_app(g, $value0);
const ANY * $value2 = purs_any_app(f, $value1);
return $value2;

At least one benefit of this is that it makes it easier to set breakpoints in generated programs. I am currently performing these transformations by hand when debugging generated output.

https://github.com/purescript/purescript/blob/master/src/Language/PureScript/CoreImp/Optimizer/Inliner.hs

Implement an equivalent for the inlineCommonOperators pass in PureScript.

https://github.com/purescript/purescript/blob/master/src/Language/PureScript/CoreImp/Optimizer/Inliner.hs#L109

I think a good few hours can be sunk into this one alone, but will be worth it. We should be able to apply the extra optimization of unboxing literals where applicable or even statically computing results where applicable. For reference, see: https://github.com/pure-c/pure-c/blob/cb4c6ffad5af96928c5934ea29138fbb9ae708a3/src/Language/PureScript/CodeGen/C/Optimizer/Inliner.purs#L222-L242

Required by #12