On Thu, Mar 20, 2014 at 1:10 PM, Andrew Dalke <[email protected]> wrote:
> On Mar 20, 2014, at 10:07 AM, Robert Kern wrote:
>> I think the operator-overload-as-DSL use cases actually argue somewhat
>> for right-associativity. ... Right-associativity adds some diversity
>> into the ecosystem and opens up some design space.
>
> You say that like it's a good thing.
Hey, I just want a multiplication operator. You're the one who wants a
new DSL toy. ;-)
> My argument is that anything which adds another line to Python's
> precedence table is a bad idea. Unless there's a really good reason
> for it. The two examples were the best I could come up with, and I don't
> think they are that persuasive.
Really? I mean, |, ^, and & *each* get their own precedence level. I'm
not really sure that there is an aversion to adding precedence levels.
In fact, it almost seems like the opposite: everything gets its own
level unless if they obviously go together.
> Looking at the table, the only places for it are on the *, /, //, %
> line or on the ** line. Since ** is right-associative, then the
> diversity argument combined with the "no new line" argument means
> @ should be on the same line, and with the same precedence, as **
>
> In DSL space, that means @ could be used as the inverse of ** by those
> who want to discard any ties to its use in numerics. Considering it
> now, I agree this would indeed open up some design space.
>
> I don't see anything disastrously wrong for that in matrix/vector use,
> though my intuition on this is very limited. I believe this gives
> results like the "strong right" option, no?
>
>
> As an observation, if this is done, and if you want operators to look
> symmetrical at the syntax level, and if a matrix exponentiation
> operator isn't critical, then perhaps use '@@' for matrix multiplication,
> and leave '@' for decorators? It would be a small reminder that '@@'
> has higher precedence than '*', and may help reduce the momentary
> confusion upon seeing something like
>
> @a@b
> @c
> def f():
> pass
The decorator syntax is deliberately limited to prevent this: you
can't put an arbitrary expression after the initiating @, just a
(potentially dotted) name that may or may not be called maybe with
some arguments. One couldn't do this, for example:
[~/scratch]
|1> s = """
..> @a+b
..> def f():
..> pass
..> """
[~/scratch]
|4> compile(s, '<string>', 'exec')
File "<string>", line 2
@a+b
^
SyntaxError: invalid syntax
--
Robert Kern
_______________________________________________
NumPy-Discussion mailing list
[email protected]
http://mail.scipy.org/mailman/listinfo/numpy-discussion
