feat(pp): pretty print implementation draft

[lushoBarlett]

Compiles without warnings for now...

I will draft this because I need some suggestions:

1. Should I do the "missing case" bit? I don't think its necessary.
2. How can I test this? (where should I wire the pretty_print function?
3. What behavior is expected of this function regarding "width"?

Closes #136.

Progress so far (basic_op.jp)

I've made incredible progress but seem to run into a couple of problems. First I get this weird addresses, I get them only in some cases I think I can figure each one out with time. Secondly (and I might need a hand with this) is that I can't find a way to output tabs + braces + endlines + semicolons in a way that satisfies all cases. This is due to the fact that Block exists I think, and that it sometimes is a child of an if statement and sometimes it is not. Should I just add context to the block printing? Wonder what your thoughts are... By all means test it yourself if you'd like...

int_val := 1 + 2 + 3 + 4;
float_val := 1.0 + 1.5 + 1.0;
string_val := "test" + "ing" + ".";
int_div := 1 / 2;
float_div := 1.0 / 2.0;
litt := fn () {
        return true;
};
litf := fn () {
        return false;
};
nullv := fn () {
        return null;
};
logic_ops := fn () {
        answer := 1 >= 1 && 1 <= 1;
        if (1 > 1 || 1 != 1) {
                        return false;
}
        return answer;
};
p_aux := fn (x) => x + 7;
pizza := fn () => 6 |> p_aux();
sum := fn (a, b) => a + b;
issue261 := fn () => 10 |> sum(0x7e21787e11c8);
if_else_if := fn () {
        i := 2;
        if (i == 1) {
                        return false;
} else {
                if (i == 3) {
                                        return false;
} else {
                        if (i == 2) {
                                                        return true;
}
                }
        }
        return false;
};
ternary := fn () {
        i := 0;
        return if (i == 1) then 0 else 1 + if (i == 0) then i + 1 else 0;
};
array_access := fn () {
        arr := array { 0x7e21787e1b58; 0x7e21787e1b88; 0x7e21787e1bb8; 0x7e21787e1be8; 0x7e21787e1c18};
        arr[0] = 1;
        arr[4] = 5;
        return arr[0] + arr[1] + arr[2] + arr[3] + arr[4];
};
a := 2 - 1;
b := 2 - 1;
c := 2 - 1;
d := 2 - 1;
e := 0x7de1787e65701;
f := 0x7de1787e65c01.1;
g := 0x7de1787e66101;
h := 0x7de1787e66601.1;
expressions_as_statements := seq {
        1 + 1;
        "hello";
        fn () => seq {
                return 0;
        };
        true;
        1.1;
        0;
        return 0;
};
ternary_disambiguations := seq {
        if (1 + 1 == 2) then "YES" else "NO";
        if (1 + 1 == 2) then "YES" else "NO";
        x := fn (a) => true;
        if (x(0x7e21787e3028)) then 1 else 0;
        if (true) {
                        if (true) then 1 else 0;
}
        bar := false;
        if (bar) {
        {
                        print(0x7e21787e3358);
                }}
        if (1 == 1) {
                        1 + 1;
}
        result := 0;
        return if (if (false) then false else true) then 1 else 0;
};
__invoke := fn () => 0;

[SebastianMestre]

1. Should I do the "missing case" bit? I don't think its necessary.

I think assert() would be fine

2. How can I test this?

Round-tripping between pretty-printing and parsing (CST -> text -> same CST) is a good way to gain confidence in the printer, but it might be kind of arduous to write.

I'll be pragmatic and say that checking some specific input-output (cst, text) pairs is good enough. We can add regression tests if we find any bugs.

(where should I wire the pretty_print function?

I think we could use it in the playground executable. Also very low priority, so feel free to ignore/do in a separate PR.

• 3. What behavior is expected of this function regarding "width"?

You mean limiting the number of columns per line of code? It's famously pretty difficult. There is a famous paper by Philip Wadler outlining a pretty decent and simple approach.

Tbh I am happy with the printer in this PR (no column limit), but if you want to add that, a separate PR would be welcome.

[SebastianMestre]

There are some minor style thingies but generally LGTM -- feel free to merge when you're happy with it

[lushoBarlett]

Keep in mind I've removed the overloaded << operator for Token* because I thought it was non-deterministically colliding with just outputing pointer addresses. I seem to be wrong on that, but I chose to remove it anyways.