Add Parsing of Modifer Operators (e.g. +=) to Luna

[iamrecursion]

Summary

Currently CI is failing due to the inability of Luna to parse operators used in StdTest. This task exists to track the implementation of modifier operators into the parser and IR.

Value

Modifier operators are potentially useful functionality for our users, but this is also keeping CI in the red, reducing the availability of valuable feedback to team members.

Specification

• Design IR for such operators (either raw or as a desugaring).
• Implement IR for these operators.
• Implement parsing for such operators in the parser.

Acceptance Criteria & Test Cases

• Luna successfully parses modifier operators into valid IR.
• StdTest passes on CI with the FieldModifications test enabled.

[iamrecursion]

An additional example of this breakage is in #368.

[iamrecursion]

#355 is also this same bug.

[iamrecursion]

A big issue with this is that it's currently breaking the ability to have a simple != or /= not-equal-to operator work.

[wdanilo]

Continuing the discussion from here (https://github.com/luna/luna/issues/368) :

@mwu-tow == is not a valid case here as the = is already a special kind of an operator and having a modifier == would not make sense.

@iamrecursion I would rather not special case something. There are many other options possible / questions involved:

• Should we allow for prefix operators? I know that not operator would be cool, but we've got an incredibly small amount of use cases for them so far, so maybe its better to go the Haskell way here (this is still an open discussion and we need to finish it soon)
• Should ! be the negate operator? Why not ~? From a mathematical perspective, it's much more valid to use ~ for that purpose. Moreover, we were planning to use ! as a syntax for possible errors like, foo : Int in IO ! IOErrror. Then it would be compatible with !=, as there would not be an ! operator.

[iamrecursion]

We can perhaps sidestep the question about prefix operators for now, we do need some construct for expressing ‘not equal to’ that doesn’t run afoul of this field modifiers issue.

While actually implementing field modifications is important it, in my view, is not as high priority is unbreaking the ability to express !=, whatever the chosen syntax is.

Field modifications themselves are a touch more complicated as they require interpreter support which doesn’t yet exist, but will as part of the new interpreter. I do believe, however, that we haven’t decided the semantics of field modification, or if we have that it isn’t written down anywhere.