[Numpy-discussion] [help needed] associativity and precedence of '@'

[Robert Kern]

On Thu, Mar 20, 2014 at 8:38 PM, Andrew Dalke <dalke at dalkescientific.com> wrote:

> You say "we've been asked to report back on what design of @ will
> be best for the numeric community, since that's where we have special
> expertise that python-dev lacks." I don't really think that goal
> means you can avoid considering all non-numeric consequences.

Sure, but that discussion will (and should) happen on python-ideas.
When Nathaniel says that "we have been asked" to answer this very
specific question, he means that literally. Guido has asked us to
answer this specific question, not for our community's collective
judgement call on the total question. Our answer will be considered
along with other concerns (like the operator abuse-case) on
python-ideas to end up at the final decision weighing all of the
factors. We're trying to avoid the Abilene Paradox.

> On Mar 20, 2014, at 2:31 PM, Robert Kern wrote:
>> 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.
>
> No new expression precedence level has been added since ** in
> January 1996, at least, not that I can identify. Those boolean ones
> you mentioned  were added in October 1991 and follows the C operator
> precedence. Given the number of other languages do the same, and
> Python's goals, this makes sense. The ** was a secondary influence
> by Fortran.
>
> The closest Python came since 1996 is support for the if/else
> expression, but that has the same precedence as lambda. Eg,
> compare 3.4:
>
>    test: or_test ['if' or_test 'else' test] | lambdef
>
> to 1.5.2:
>
>    test: and_test ('or' and_test)* | lambdef
>
> (The documentation says they are at different levels, but
> they actually are at the same. Consider:
>   lambda: 1 if print('hi') else print('bye')
> This is not the same as
>   (lambda: 1) if print('hi') else print('bye')
> .)

The observed parse is consistent with `if-else` having a higher
precedence than lambda, as documented. If they *were* at the same
level, the parse would be the paranthesized expression that you cite
(just as 5%2*3 == (5%2)*3 != 5%(2*3)).

> If you came from a Pascal background then you would expect
> '+' '-' 'or' and 'xor' to have the same precedence, since
> the adding operators obviously go together.
>
> While, oddly enough, C's == is not at the same level as <=,
> which suggests that the Dennis Ritchie at one time didn't
> think it was obvious that those two go together. (Then again,
> he also started off with a =- 1 instead of a -= 1.)
>
> The arguments against a complex precedence table are
> well-trod ground. See:
>   http://stackoverflow.com/questions/6320424/
>   http://c2.com/cgi/wiki?OperatorPrecedenceConsideredHarmful
>
> Larry Wall's summary about operator precedence in
> http://perl6.org/archive/doc/design/apo/A03.html is apropos
> to the general topic of deciding upon operator precedence.

I see a lot of assertions of fact there, but no empirical studies that
actually make them facts.

On that note, I wonder if we can convince Stefik and Siebert et al. to
run a study for us to help answer these questions. If I were in their
group, I'd jump at the chance to use their empirical methodology to
help design an actual production language.

  http://neverworkintheory.org/2014/01/29/stefik-siebert-syntax.html

-- 
Robert Kern