Unify argument names for assignment, binary, unary operators

[bmcdonald3]

Currently, among the different data structures, there are various argument names for assignment, binary, and unary operators, but these would make sense to unify. Capturing some proposals that have been brought up in conversation below, please comment any additional proposals that you have in mind.

Proposed argument naming conventions

Type of operation	positional	minimal	descriptive	others
assignment (=)	lhs/rhs	x/y	destination/source	a/b, dst/src
op= assignment (e.g.,+=)	lhs/rhs	x/y	lefHandSide/rightHandSide	a/b. dst/src
binary (e.g, +)	lop/rop	x/y	leftOperand/rightOperand	a/b
unary (e.g., !)	op	x	operand	a

At some point, a straw poll would probably be the quickest way to settle these for the individual cases, but thought it would be worthwhile to collect all proposals first.

[bradcray]

I feel pretty unhappy about a and b for some reason—maybe just because they don't seem very math-y (for mathematical operators). If someone has a rationale for them other than "that's what whoever wrote the first Chapel operator used, and we've continued since then," I'd be curious to hear it.

I feel better about x and y which feel more like natural math-y names for operator arguments, but they still seem unnecessarily succinct / non-descriptive. So I'm open to them, but maybe not excited by them?

For = and op= I feel quite good about lhs and rhs as being succinct, unique, and reasonably clear (to those in the know... and maybe a Chapel abbreviation glossary somewhere could help those who aren't).

I'm not crazy about lop and rop though they seem somewhat symmetrical / similar to lhs and rhs.

I also wonder how strict we want to be with these vs. thinking of them as guidelines if you have no better ideas. For example, for a += overload on sets that takes a collection and a singleton element, I could imagine someone wanting to write operator collection.+=(ref coll: collection, in elem: collection.eltType); rather than using generic lhs and rhs to emphasize the asymmetry and role between the operands.

Pointing out the obvious: these names currently only matter for the documentation and implementation of the routines since operators are currently infix, so can't be called in a "pass by keyword" style. That said, at times in the project's history, we've discussed permitting operators be called in a prefix-parenthesized mode (e.g., +(1, 2)) in which case they could be.

[mppf]

FWIW I'd be happy with @bradcray's suggestion above - lhs rhs for the = and variants - and x y for the other operators.

[lydia-duncan]

Since operator argument names can't be referenced by users, we've decided not to stabilize these for 2.0 (but will probably look into unifying them later)