user-defined operators: a very modest proposal

[Steve R. Hastings]

I have been studying Python recently, and I read a comment on one
web page that said something like "the people using Python for heavy math
really wish they could define their own operators". The specific
example was to define an "outer product" operator for matrices. (There
was even a PEP, number 211, about this.)

I gave it some thought, and Googled for previous discussions about this,
and came up with this suggestion:

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

I'm not any kind of language design expert, but this seems to me like a
syntax that would be easy for Python to recognize. Because the square
braces are reversed from the usual "[]" order, this should not look like
any currently-valid code. And square braces, IMHO, do not fail the
"low-toner printout" test. (Some earlier proposals included operators like
"~+" and these were deemed too hard to read.)

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.

It should be possible to define operators using punctuation,
alphanumerics, or both:

]+[
]add[
]outer*[
Examples of use:

m = m0 ]*[ m1
m = m0]*[m1

m = m0 ]outer*[ m1
m = m0]outer*[m1

It looks a lot better with the white space, I think, but it's not horrible
without the white space.
Also, there should be a way to declare what kind of precedence the user-defined
operators use. Python already has lots of operators with different precedence,
and I think the best way is just to indicate which Python operator the new
operator's precedence should match:

class MyExcellentMatr ix(object):
@precedence('*' )
def __op_outer*__(s elf, right):
# ...do stuff...

I think a decorator is a good way to set the precedence.
Perhaps the default precedence should be that of '+'.

Augmented forms should be supported:

]+=[
]*=[
]outer*=[
Examples:

m ]*=[ m0
m]*=[m0

m ]outer*=[ m0
m]outer*=[
Either I actually have made a sensible suggestion, or else people will now
explain why this idea isn't good (and I'll learn something). Either way,
I look forward to your comments.

References:

Elementwise/Objectwise Operators
http://www.python.org/peps/pep-0225.html
Adding A New Outer Product Operator
http://www.python.org/peps/pep-0211.html
--
Steve R. Hastings "Vita est"
st***@hastings. org http://www.blarg.net/~steveha

[Tom Anderson]

On Tue, 22 Nov 2005 je****@unpython ic.net wrote:

Each unicode character in the class 'Sm' (Symbol,
Math) whose value is greater than 127 may be used as a user-defined operator.
EXCELLENT idea, Jeff!
Also, to accomodate operators such as u'\N{DOUBLE INTEGRAL}', which are not
simple unary or binary operators, the character u'\N{NO BREAK SPACE}' will be
used to separate arguments. When necessary, parentheses will be added to
remove ambiguity. This leads naturally to expressions like
\N{DOUBLE INTEGRAL} (y * x**2) \N{NO BREAK SPACE} dx \N{NO BREAK SPACE} dy
(corresponding to the call (y*x**2).__u222 c__(dx, dy)) which are clearly easy
to love, except for the small issue that many inferior editors will not clearly
display the \N{NO BREAK SPACE} characters.
Could we use '\u2202' instead of 'd'? Or, to be more correct, is there a
d-which-is-not-a-d somewhere in the mathematical character sets? It would
be very useful to be able to distinguish d'x', as it were, from 'dx'.
* Do we immediately implement the combination of operators with nonspacing
marks, or defer it?
As long as you don't use normalisation form D, i'm happy.
* Should some of the unicode mathematical symbols be reserved for literals?
It would be greatly preferable to write \u2205 instead of the other proposed
empty-set literal notation, {-}. Perhaps nullary operators could be defined,
so that writing \u2205 alone is the same as __u2205__() i.e., calling the
nullary function, whether it is defined at the local, lexical, module, or
built-in scope.

Sounds like a good idea. \u211D and relatives would also be a candidate
for this treatment.

And for those of you out there who are laughing at this, i'd point out
that Perl IS ACTUALLY DOING THIS.

tom

--
I DO IT WRONG!!!

[Fredrik Lundh]

Joseph Garvin wrote:

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.

What do you mean by unicode operators? Link?

a few messages earlier in the thead you're posting to. if your mail or news
provider is dropping messages, you can read the group via e.g.

http://news.gmane.org/gmane.comp.python.general

jeff's proposal is here:

http://article.gmane.org/gmane.comp....general/433247

</F>

[Simon Brunning]

On 23/11/05, Joseph Garvin <k0*****@kzoo.e du> wrote:

What do you mean by unicode operators? Link?

http://fishbowl.pastiche.org/2003/03...d_operator_set

--
Cheers,
Simon B,
si***@brunningo nline.net,
http://www.brunningonline.net/simon/blog/

[Fredrik Lundh]

Simon Brunning wrote:

What do you mean by unicode operators? Link?

http://fishbowl.pastiche.org/2003/03...d_operator_set

see also:

http://www.brunningonline.net/simon/...es/000666.html
http://www.python.org/peps/pep-0666.html

</F>

[Simon Brunning]

On 23/11/05, Fredrik Lundh <fr*****@python ware.com> wrote:

see also:

http://www.brunningonline.net/simon/...es/000666.html
http://www.python.org/peps/pep-0666.html

PEP 666 should have been left open. There are a number of ideas that
come up here that should be added to it - and i'm sure there'll be
more.

--
Cheers,
Simon B,
si***@brunningo nline.net,
http://www.brunningonline.net/simon/blog/

[bruno at modulix]

Joseph Garvin wrote:

Tom Anderson wrote:

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.

s/expressiveness/unreadability/
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom. gro'.split('@')])"

[Kay Schluehr]

Steve R. Hastings wrote:

It should be possible to define operators using punctuation,
alphanumerics, or both:

]+[
]add[
]outer*[

Seems like you look for advanced source-code editors.Some ideas are
around for quite a while e.g. here

http://en.wikipedia.org/wiki/Intentional_programming

I'm not sure if current computer algebra systems also offer a WYSIWYG
input mode? Of course this is not clutter and line noise but domain
specific standard notation.

There has also been a more Python related ambitious multi-language
project called Logix that enabled user-defined operators but it seems
to be dead.

Kay

[Antoon Pardon]

Op 2005-11-22, je****@unpython ic.net schreef <je****@unpytho nic.net>:

* Should some of the unicode mathematical symbols be reserved for literals?
It would be greatly preferable to write \u2205 instead of the other proposed
empty-set literal notation, {-}. Perhaps nullary operators could be defined,
so that writing \u2205 alone is the same as __u2205__() i.e., calling the
nullary function, whether it is defined at the local, lexical, module, or
built-in scope.

Isn't this essentially already happening with lists?.

And isn't something like this already possible with properties, except
for the scoping.

If python would develop the property idea a bit further and have
variables that would call a function each time they are accessed,
something like this could work.

--
Antoon Pardon