User defined operators

[claban3]

This adds expression level user-defined operators into Hazel. Some important tidbits of information for testing these changes:

• Precedence and associativity of operators are determined by the first operator in the user op (though the next thing-to-do is determining precedence by looking at each operator in the user op).
• Operators are defined in let patterns by constructing on top of wildcards, and currently must be surrounded in underscores in order for them to be used as binary operators in expressions. (Future work could be to customize fixity like in Agda).
• User operators are constructed in expressions by constructing operators on top of hazel-defined operators (e.g. <+>+ --> ++).
• Type checking of user ops is the same as for 2-ary functions.

This PR also attempts to standardize the precedence of type level operators. Please verify the "type precedence test" in SkelParserTests.re.

[dm0n3y]

Gotta resolve conflicts first by merging in dev into your branch

[claban3]

• It is not possible to shadow the built-in operators, e.g. _+_. This may be a good thing, but if so we should probably have a warning / error on bindings of those.

Makes sense, I will add a "got reserved operator" error to the cursor context menu. However,

• It is not possible to use the "." in custom operators. Again this may be for the best given the other ways we are using ".", but it makes it so you can't define float versions of things using the same idiom as built in operators.

I'm not sure what would make sense as valid feedback in this situation? Maybe treat it as invalid text? I don't think the float idiom makes sense here, because you could create an operator of type int -> float -> int for example.

[cyrus-]

I'm not sure what would make sense as valid feedback in this situation? Maybe treat it as invalid text? I don't think the float idiom makes sense here, because you could create an operator of type int -> float -> int for example.

imo we can just let the users make sure it makes sense to put the dot in their operator from the perspective of notational convention (with maybe a future style checker / linter warning in questionable situations)

[claban3]

imo we can just let the users make sure it makes sense to put the dot in their operator from the perspective of notational convention (with maybe a future style checker / linter warning in questionable situations)

So add . to the user defined operator regex?

[cyrus-]

Actually let's hold off on that for now, that might cause trouble with float parsing and with labeled tuple stuff that Erin is working on. we can return to that question in the future.

[claban3]

Sounds good!

[dm0n3y]

@claban3 could you comment with a screenshot example of defining an operator and using it?

[claban3]

Analytically:

Synthetically:

[claban3]

Let me know if you want more examples

[cyrus-]

Archiving this because it cannot be merged into Hazel 3, but we are planning to follow the same specification more-or-less -- cross-referenced in #828. Thank you for all the hard work on this @claban3 !