RFC -- custom operators

[Rhodri James]

On 07/08/18 08:58, Steven D'Aprano wrote:
> Request for comments -- proposal to allow custom binary operators.
[snip]
> (1) This proposal requires operators to be legal identifiers,
>      such as "XOR" or "spam", not punctuation like % and
>      absolutely not Unicode symbols like ∉

Probably wise.  I'd personally be inclined to use expressive symbols 
because I, of course, am an entirely reasonable person whose every 
choice will be completely intuitive to everyone else (ho ho), but I can 
imagine other people succumbing to the temptation to trying turning 
Python in APL.

Also names are probably easier to parse.

> (2) For the sake of the functional requirements, assume that
>      we can parse `spam OP eggs` without any ambiguity;

Seems like a fair assumption.

> (3) This only proposes binary infix operators, not unary
>      prefix or postfix operators;
> 
>      infix:    argument1 OP argument2
>      prefix:   OP argument
>      postfix:  argument OP

Other than being easier to parse, is there any particular reason for 
this choice?

> (4) This does not propose to allow the precedence to be
>      set on a case-by-case basis. All custom operators will
>      have the same precedence.
> 
> (5) What should that precedence be?

Low.  Names, with their mandatory surrounding spaces, feel more 
separated and hence lower priority than their operands.  I would expect

   x + 1 FROBNICATE q * 4 - 2

to parse as

   (x + 1) FROBNICATE (q*4-2)

> (6) This does not propose to set the associativity on a
>      case-by-case basis. All custom operators will have
>      the same associativity.
> 
> (7) Should the operators be left-associative (like multiplication),
>      right-associative (like exponentiation), or non-associative?

Either left-associative or non-associative, probably the latter.  Most 
operators that I can think of are left-associative, but you probably 
want non-associative to avoid subtle bugs with more naturally 
right-associative operators.

> (If there aren't any such use-cases, then there's no need for custom
> operators.)

I can't think of any use cases I actually want off-hand.  The sorts of 
things I might apply new operators to are various bits of byte buffer 
mangling, and most of those feel more pythonic as iterative processes.

-- 
Rhodri James *-* Kynesim Ltd