On 3/26/07, Charles R Harris <[EMAIL PROTECTED]> 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 _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
