feat(compiler)!: Change -> to => in type signatures

[alex-snezhko]

Closes #1179 (supersedes)

[spotandjake]

This looks good to me.

I don't fully understand the code in the lever hack that checks the data types but what I did understand looks good.

[ospencer]

Fantastic work here!

[marcusroberts]

If Oscar's happy with the parsing, this looks great.

One question, can we use the formatter or provide a utility to help people bulk change their code to the new style?

[peblair]

Two comments:

1. I would love to see some stress tests/weird cases which should not parse (let f = (foo, bar) => Number) in the test suite
2. Extremely minor concern: just want to double-check other Core Team members (cc @ospencer and @phated especially) are cool with this possibly introducing some potential confusion for new users (e.g. let lexer : (stream) => List<Token> might look to a new user like stream is supposed to be the name of the function argument and not a placeholder type).

[spotandjake]

2. Extremely minor concern: just want to double-check other Core Team members (cc @ospencer and @phated especially) are cool with this possibly introducing some potential confusion for new users (e.g. let lexer : (stream) => List<Token> might look to a new user like stream is supposed to be the name of the function argument and not a placeholder type).

I feel like the issue of the confusion was already there before the arrow change.

[peblair]

I feel like the issue of the confusion was already there before the arrow change.

Yes, true, but the -> syntax made it a bit more clear when reading quickly that one was looking at a type, not a function definition. Maybe I am wording this scenario wrong, but I am just envisioning some potential weird interaction with the unified => syntax and placeholder type names

[alex-snezhko]

possibly introducing some potential confusion for new users (e.g. let lexer : (stream) => List might look to a new user like stream is supposed to be the name of the function argument and not a placeholder type).

@peblair A potential point of relief is that if the user is using VSCode or possibly another editor we may support integration with in the future, the LSP & syntax highlighting may allow for a form of distinguishability between parameter names and placeholder types. For example with the code

let a: stream => Number = myStream => 1

VSCode should highlight/format stream differently from myStream (assuming the color scheme they are using prints them differently of course). They will also get this code lens:

(myStream: stream) => Number

which can be useful for figuring out what is going on. Not perfect, but it's something at least

[alex-snezhko]

@peblair I added some parsing tests to types.re; are those the sort of cases you had in mind?

[phated]

Going to merge this, we can always add more tests later 🎉