The following program does not work:

var Array:Int a
function foo i
  arg_rw Int i
  i := 3
foo a:size

The reason is that the setfield.pli module has to be extended so that it overwrites the functions call compiling mechanism in order to compile the previous program as:

var Array:Int a
function foo i
  arg_w Int i
  i := 3
var Int j
j := a size
foo j
a 'size :=' j


Setting 'decommit_step' in /pliant/language/declare/struct.c will prevent 'process_restore' in dump.c to work in some rare cases. It means that freeing the pages of large free chunks in the memory (the improvement I added to Doug Lea algorithm) is buggy.
Using 'function' as an identifier for a local variable seems to have bad effects on the code generator.

This is only the tip of a tricky problem with the Pliant compiler: incorrect handling of backtracking in the high level compiler. Backtracking means uncompiling an expression because several instances succeeded to compile the expression and another one has finally been selected. When compiling the expression has some side effects (such as adding a field to a data type) backtracking may be tricky and is poorly handled in the current implementation of the compiler.

There may also be other bad side effects in the Pliant high level compiling mechanism. Say you compile an expression that defines a few keywords then asks its arguments to compile; if the function fails then the successful compilation of the arguments can be semantically incorrect, so should be reversed, but that is not automatically done for compilation speed reasons. The expression is responsible for uncompiling its arguments before exiting in such a situation, but I have not yet carefully checked all the Pliant system against that so there are surely some remaining bugs here.


Pliant uses reference counting rather than a garbage collector. The reason is performance; see Pliant design for the arguments about this design choice.
In order to help check the possible memory leaks due to circular references, when executing at debugging level 2, before exiting, Pliant will unlock the roots and, as a result, all objects up to the last one should get freed and all bytes of dynamically allocated memory should be freed. Now the problem with this very useful feature (that greatly helps tracking memory leaks due either to circular references or to explicitly allocated areas that have not been freed) is that types and functions are Pliant objects so these will be freed as well. Also when an object is built, its type reference count is not incremented so objects may get freed in the wrong order and lead to a core dump.