[Numpy-discussion] New Operators in Python

Bill Baxter wbaxter at gmail.com
Sun Mar 25 21:31:04 EDT 2007


On 3/26/07, Charles R Harris <charlesr.harris at gmail.com> wrote:
>
> What might work better is simply some sort of sign that causes a function to
> be parsed as infix, x @dot y for instance, although Python already uses @
> for other things. I don't know what symbols are left unused at this point,
> maybe ! , $, and ~.

I'm not really an expert on compilers, but from what I understand, the
biggest problem with adding new operators is defining precedence.
Without it, the interpreter won't know what to do with something like
A @dot B @plus C.  Currently the interpreter only has to look at what
the tokens are to build a parse tree out of something like A*B+C.  It
doesn't matter what the types of A B and C are, that's always parsed
as (A*B)+C.  If you add a @dot operator where do you define its
precedence?  On the class that defines the operator?  What if two
classes define the same operator with different precedences?  It gets
to be a big ambiguous mess.

So if you're going to add new operators they pretty much need to have
globally predetermined precedence to allow the parser to remain sane.
I think it's ML or Haskell that lets you define any operator you want
out of the core operator tokens (eg "*+*") but IIRC the first char
determines the precedence.  So *+* has the same precedence as "*".
Requiring the new operator to include an existing operator char seems
like a reasonable strategy since it gives a simple rule-based
mechanism for determining precedence that is easy for both the parser
and for users.

--bb



More information about the NumPy-Discussion mailing list