Attempting to build the following polyglot code into Lua gives the error Lua requires inclusive ForRange.

$a <- 1;
$a <- 1;
$a <- 1;
$a <- 1;
$a <- 1;
$a <- 1;
$a <- 1;
$a <- 1;
$a <- 1;
for $b 1 10 {
};

Removing one or more of the assignments fixes the error, but it seems having 9 or more assignments causes a bug.

Compiling

if (1==1) { println 1; } { println 2; };

to Python produces

if 1==1:print(1)else:print(2)

This is a syntax error, it should produce

if 1==1:print(1)
else:print(2)

Usage: $increment <- (func $x:-oo..oo ($x+1)); Recurisve functions should work but need to be type annotated:

$fac:(Func 0..oo 0..oo) <- (func $x:0..oo
    (conditional ($x == 0) 1 (($fac ($x-1):0..oo) * $x))
)

It's in a bit of a rough state, so marking this as draft for now. Pretty much everything is an s-expression.

In particular, I want to avoid the need for parentheses around statements. Requiring a semicolon would work I guess.

Added valueType key to nodes. Builder functions now set the valueType based on child nodes. There's no type checking. Identifiers don't know their types.

Now that I thing about it it might be better to create all the nodes as typeless and then run a plugin that would annotate the nodes (knowing the varDeclarations information).

This started as removing applications and evolved to refactoring the IR completely (split IR.ts into files, move unrelated files into common/).

Some applications have not been converted yet, so I have marked this as draft. In particular:

• print + println should be their own Print node with a flag for trailingNewline
• str_length ?
• cardinality ? maybe also rename into two nodes: one for List, one for Table
• int_to_str should be unary op
• str_to_int should be unary op
• sorted should be an unary op?
• str_get_char should be its own node by analogy with ArrayGet
• contains_key, contains_value, and indexof should be their own nodes?

Get rid of src/languages/debug as we now have Polygolf target for debugging.

Replace debugEmit's usage in /src/plugins/loops.test.ts with markdown tests.

Adds a boolean switch to MethodExpr to treat a method call as a property. Useful for languages such as C# and Swift. For example, Swift needs text.count rather than text.count().

Adds support for markdown defined test suites. The markdown tests are automagically compiled to typescript Jest code.

To create such suite, create a markdown file with a ".test.md" extension. Headings are used to group the tests (using Jest's describe). Code blocks are used to define the actual tests. All other markdown syntax is ignored.

Each codeblock is required to have the language annotation and optionally other test parameters/options/commands (all space-separated). If the language is polygolf (with no other options) it denotes an input, otherwise an output. Multiple output blocks can relate to a single input block. If a codeblock title contains "skip" it's not used to generate tests.

See loops.test.md for how it is used for plugin testing. See nim.test.md for how it is used for language testing.

Implements #59 .

Despite the branch name, the primary contribution of this PR is a read-only IR state. This removes the need for structuredClones, which are pretty expensive compared to the alternative (just pass stuff around, knowing it will not get mutated).

With the read-only IR state, I rewrote all of the plugins to use the new read-only APIs and restricted what plugins can do: each plugin is now a visitor that takes a node (and its parents) and returns undefined for no change or the new node if it suggests a change. Plugins are utilized in two ways:

1. applyAll in applyLanguage.ts: apply the plugin over the whole tree, and replace every node it suggests to replace. This mode is used in emit plugins to ensure that all of their changes are applied, such as converting all exclusive for-ranges to inclusive for-ranges.
2. one replacement at a time: this is used in the BFS search. The search creates a new program by replacing the node, then considers that new program as a valid state to push to the queue. So if a plugin suggests a replacement for each of 5 nodes, the search continues on those 5 new programs.

The key to immutable actions is Spines as a replacement for the old Path. A spine is just a node with its parents, together with some helper functions. Spines make immutable actions quite natural, similar to how git branches make immutable commits natural as well. (I think I got the inspiration for Spines from some Anders Hejlsburg interview where he seemed to indicate it's what TypeScript uses (I am not sure about this claim)).

The main reason immutable nodes are faster than structured clones is the ability to re-use nodes: In the tree (add A B), swapping the arguments to get (add B A) costs as little as just constructing a new "add" node and re-using the old pointers to the A and B subtrees. To get a new program with N changed to node M, it is enough to construct a new node like N.parent but with N changed to M, a new node like N.parent.parent but with N.parent changed to the new N.parent, etc. So it just needs to re-make the parent nodes to create an entirely new program tree, so replacing a node immutably is average-case O(log(N)) in the number of tree nodes.

TODO:

• [x] add a description of spines and stuff to architecture.md
• [x] consider what happens if an alternative includes another, like if swapBinaryOps was used (for some reason) as an emitPlugin for a + (b + c)). This has realistic potential in nested exclusive for-loops converted to inclusive for-loops. I'm not sure if I got the visit order right here.
• [x] comment the code a bit more

Fixes a syntax error in Python if-else generation, raised in #46. Correctly handles indentation at multiple levels as confirmed by compiling

if(1==1) {
    if (2==1) { 
        println "a"; 
    } { 
        println "b"; 
    };
} {
    if (3==1) { 
        if (4==1) { 
            if (5==1) { 
                println "c"; 
            };
        } { 
            println "d"; 
        };
    } { 
        println "e"; 
    };
};

Sidenote: This would probably be a good program to include in a test suite.

So do like polygolf -i src/programs/fibonacci.polygolf -l all -o fibonacci and it will output to fibonacci.lua, fibonacci.nim, etc.

Another possible thing is that instead of having -o fibonacci, you can have an option like --cg that will automatically upload everything to code.golf (of course, you have to input your token or whatever).

Compiling

print (text_split "abc" "b");

to Nim produces

include re
"abc".split "b".echo

which throws a type error

Compiling

print true;

to polygolf produces

print (true);

which when fed into the parser produces a syntax error. Most likely this should not be a syntax error.