I think it would be a big advantage if the C and spin compilers for the P2 would support operator methods.
For those who are not familiar with C++, operator methods work like this:
You declare a function, for example
Vector3D operator+ (const Vector3D& a, const Vector3D& b);
res.x= a.x + b.x;
res.y= a.y + b.y;
res.z= a.z + b.z;
Now, every time you write "c = a + b;" (all variables are of type Vector3D) the compiler translates this to a call to the function as if you wrote "c = operator+ (a, b);". This not only makes the code much more readable but would allow that data types like 64 bit integers or double precision floats don't have to be implemented in the compiler itself but could be built in normal code by any user. By using inline assembler it could be even done very efficiently, I think.
As the method calls are only "syntactical aliases" no extra code generation or byte codes for the interpreter are needed. It would just require some extension to the parser.
Because there are no structs or classes in spin user defined operators would require some special calling conventions. Also, the above example (originally C++ code) would not work in FlexC because there is no new() and no constructor/destructor methods. Creating "res" on the stack would probably work for a single call but not if (a+b) is part of a longer formula. The result would be overwritten by the next function call.
Probably we could use the multiple return value mechanism for this. We could restrict the data types used for operator methods to small arrays which would still allow the implementation of 64 bit integers, doubles, vectors and matrices.