Somehow, these have always been right-associative, when the natural thing to expect is left-associativity. It now matters when trying to crawl down binary tree to display them properly.
This allows for a more fine-grained control over how the traces are showed. Now users can instrument the compiler to preserve only their user-defined traces, or the only the compiler, or all, or none. We also want to add another trace level on top of that: 'compact' to only show line numbers; which will work for both user-defined and/or compiler-generated traces.
This improves error messages for `a |> b(x)`.
We need to do a special check when looping over the args
and unifying. This information is within a function that does not belong
to pipe typer so I used a closure to forward along a way to add
metadata to the error when the first argument in the loop has a
unification error. Simply adding the metadata at the pipe typer
level is not good enough because then we may annotate regular
unification errors from the args.
Bumped into this randomly. We do correctly parse escape sequence, but
the format would simply but the unescaped string back on save. Now it
properly re-escapes strings before flushing them back. I also removed
the escape sequence for 'backspace' and 'new page' form feed as I
don't see any use case for those in an Aiken program really...
When rendering missing or redundant patterns, linked-list would
wrongly suggest the last nil constructor as a pattern on non-empty
list.
For example, before this commit, the exhaustivness checker would yield:
```
[(_, True), []]
```
as a suggestion, for being the result of being a list pattern with a
single argument being `(_, True) :: Nil`. Blindly following the
compiler suggestion here would cause a type unification error (since
`[]` doesn't unify with a 2-tuple).
Indeed, we mustn't render the Nil constructor when rendering non-empty
lists! So the correct suggestion should be:
```
[(_, True)]
```
KtorZ