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!!!
--
http://mail.python.org/mailman/listinfo/python-list
