Resugar binary primitive functions

[mattpolzin]

Description

This PR is an implementation of the proposal found in issue #3711.

In short, this PR resugars primitives like prim__strAppend to their almost ubiquitous in-code names (e.g. the infix form of ++ instead of prim__strAppend). Like all resugaring, this only impacts inspecting code as can be done via the REPL, IDE protocol, or LSP.

Self-check

• This is my first time contributing, I've carefully read CONTRIBUTING.md
  and I've updated CONTRIBUTORS.md with my name.
• If this is a fix, user-facing change, a compiler change, or a new paper
  implementation, I have updated CHANGELOG_NEXT.md

[buzden]

I like this. The only concern is the consistency with the current SynInfo-based resugaring. Say, for user function operation (+) 1 2 would be resugared to 1 + 2 or (+) 1 2 depending on whether fixity for + is present (unhidden) in the current syntactic context. How would primitives be resugared in the case of, say, hiding fixity declarations from Prelude.Ops?

[mattpolzin]

Thanks for taking a look.

The only concern is the consistency with the current SynInfo-based resugaring.

As far as I know, SyntaxInfo resugaring is done in the same place (well, the same Resugar module, anyway). Can you tell me what end-user experience you are thinking of where primitive operations might be resugared differently than in the code I wrote here? As far as I know, they were never resugared before (though other user-defined operators are).

Say, for user function operation (+) 1 2 would be resugared to 1 + 2 or (+) 1 2 depending on whether fixity for + is present (unhidden) in the current syntactic context.

This refers to resugaring of an operator that is already normal form right? The current work I am doing only applies to operators that have been evaluated all the way to the point of no longer being e.g. + by name, instead it would be prim__-something by name. My only point being that my code will never impact the resugaring of user-defined operators, just the primitive ones.

That all just means that I don't think there's any conflict with other resugaring. On the other hand, if you are saying that my new code should resugar e.g. prim__strAppend differently depending on whether the prelude fixity of ++ has been hidden/redefined or not, that is an interesting consideration. I'm not sure if I think it should resugar differently or not; it sounds very edge-casey.

[mattpolzin]

Marking this ready for review. It was a draft while I waited for feedback on the proposal Issue but that proposal has not generated discussion so I'll officially consider this PR up for review.