(++) can't be used as an operator since it turns into (^)

[leostera]

Problem:

The following OCaml input to refmt does not translate back to the same OCaml.

OCaml Input:

let (++) a b = a + b

Reason Output / Input:

let (++) = (a, b) => a + b;

OCaml Output:

let (^) a b = a + b

This means that libraries like notty can not be used, because they only define a (++) operator and no alternative function with a name.

Proposed solution:

Perhaps preserving all operators is impossible at this stage, but it'd be great if I didn't have to redefine operators because the OCaml output is different than what I'm expecting.

Alternatively, providing a cheatsheet of what operators will be replaced by what (and a way to circumvent it) would be a very nice gesture.

E.g,

Desc.	Reason	OCaml
String concatenation.	(++)	(^)
Value dereferencing.	(^)	(!)
Negation	(!)	not
Some custom operator	???	(++)

[jordwalke]

In this case they are swapped, so you can use Notty with ^:

echo 'let (++) = (a, b) => 0;' | refmt --print ml

Outputs:

let (^) a b = 0

If you like ++ better for Notty, I suggest doing let (++) = (^); in your Reason file.

[leostera]

I don't mind which operator symbol it uses as long as I can use it. In this case, your suggestion does not seem to work:

echo "let (++) = (^);" | refmt --print ml
let (^) = (!)

Happy to put some time into this if you can point me in the right direction.

[jordwalke]

You're right and you can see here which tokens are swapped for which tokens:
https://github.com/facebook/reason/blob/dcd42d7b071fa0ae302c1ba959590596fc466ee1/src/reason-parser/reason_syntax_util.ml#L89

[jordwalke]

I think what we could do is allow prefixing the ++ and many like it with a backslash (or suffixing it with a backslash if that avoids more conflicts) to represent "The identifier should be this literal text in the AST".

That would always give you a way to refer to any ML function identifier like:

let (++) = (++\);

Then you could use the same ++ token in Reason files.

Sometimes when formatting an identifier with a trailing \, it might print it if there is a better Reason representation. Sometimes it won't.

[anmonteiro]

#1944 should fix this when I get around to incorporating the suggested changes.