user-defined operators: a very modest proposal

[Tom Anderson]

On Tue, 22 Nov 2005, Steve R. Hastings wrote:

> User-defined operators could be defined like the following: ]+[

Eeek. That really doesn't look right.

Could you remind me of the reason we can't say [+]? It seems to me that an 
operator can never be a legal filling for an array literal or a subscript, 
so there wouldn't be ambiguity.

We could even just say that [?] is an array version of whatever operator ? 
is, and let python do the heavy lifting (excuse the pun) of looping it 
over the operands. [[?]] would obviously be a doubly-lifted version. 
Although that would mean [*] is a componentwise product, rather than an 
outer product, which wouldn't really help you very much! Maybe we could 
define {?} as the generalised outer/tensor version of the ? operator ...

> For improved readability, Python could even enforce a requirement that 
> there should be white space on either side of a user-defined operator. I 
> don't really think that's necessary.

Indeed, it would be extremely wrong - normal operators don't require that, 
and special cases aren't special enough to break the rules.

Reminds me of my idea for using spaces instead of parentheses for grouping 
in expressions, so a+b * c+d evaluates as (a+b)*(c+d) - one of my worst 
ideas ever, i'd say, up there with gin milkshakes.

> Also, there should be a way to declare what kind of precedence the 
> user-defined operators use.

Can't be done - different uses of the same operator symbol on different 
classes could have different precedence, right? So python would need to 
know what the class of the receiver is before it can work out the 
evaluation order of the expression; python does evaluation order at 
compile time, but only knows classes at execute time, so no dice.

Also, i'm pretty sure you could cook up a situation where you could 
exploit differing precedences of different definitions of one symbol to 
generate ambiguous cases, but i'm not in a twisted enough mood to actually 
work out a concrete example!

And now for something completely different.

For Py4k, i think we should allow any sequence of characters that doesn't 
mean something else to be an operator, supported with one special method 
to rule them all, __oper__(self, ator, and), so:

a + b

Becomes:

a.__oper__("+", b)

And:

a --{--@ b

Becomes:

a.__oper__("--{--@", b) # Euler's 'single rose' operator

Etc. We need to be able to distinguish a + -b from a +- b, but this is 
where i can bring my grouping-by-whitespace idea into play, requiring 
whitespace separating operands and operators - after all, if it's good 
enough for grouping statements (as it evidently is at present), it's good 
enough for expressions. The character ']' would be treated as whitespace, 
so a[b] would be handled as a.__oper__("[", b). Naturally, the . operator 
would also be handled through __oper__.

Jeff Epler's proposal to use unicode operators would synergise most 
excellently with this, allowing python to finally reach, and even surpass, 
the level of expressiveness found in languages such as perl, APL and 
INTERCAL.

tom

-- 
I DO IT WRONG!!!