[Python-ideas] Infix functions

Hannu Krosing hannu at krosing.net
Sat Feb 22 20:34:51 CET 2014


On 02/22/2014 03:45 AM, Andrew Barnert wrote:
> From: Greg Ewing <greg.ewing at canterbury.ac.nz>
>
> Sent: Friday, February 21, 2014 6:12 PM
>
>
>> Andrew Barnert wrote:
>>>      a `cross` b + c `cross` (d `dot` e)
>>>
>>>  vs.
>>>
>>>      add(cross(a, b), cross(c, dot(d, e))
>>>
>>>  Sure, it's only one character shorter (or four characters using @cross
>>>  instead  of `cross`), but you can't tell me it's not more readable.
>> It's *slightly* better, *maybe*, but it still looks
>> like a mess to my eyes, compared to
>>
>>    a % b + c % (d * e)
>>
>> There are several reasons for this version being more
>> readable:
>>
>> * It's far more compact
>> * It's not cluttered up with backticks
>> * It leverages my existing intuition about the relative
>>   precedences of the operators involved
> Sure, having an infinite number of easily-distinguishable operators that happen to have the precedence that fits your use case would be create. But we have a very limited set of operators. If you want element-wise multiplication, div, trued, and mod, there aren't any operators left with the right precedence for cross-multiplication, dot-product, and back-division. And even if that weren't an issue, using % to mean mod sometimes and cross-product other times is bound to be confusing to readers.
Why not use multiple "operator characters" for user-defined infix
operators, like postgreSQL does ?

a *% b ++ c *% (d *. e)


We could even define that the characters in the combined operator define
precendece so the
above could be written as

a *% b ++ c *% d *. e

where *% has higher precedence than *. because of (* is higher than %)
and *. has higher
precedence than *% because (. is gher than %)

Cheers
Hannu
>
> So, the perfect option doesn't exist.
>
> Backtick operators always let you write things in order, sometimes but not always let you avoid parentheses, reduce visual noise but don't dispel it completely, and do little or nothing for conciseness. They're not perfect, but they are an improvement.
>
>> Precedence is a big problem. You're assuming that backtick
>> operators would have precedence higher than '+'. What if
>> I want to define my own addition-like operator? One
>> precedence isn't going to fit all.
>
> This is another thing I already discussed this in my initial email, and I don't want to repeat myself again.
>
> They should all have the same precedence, precisely _because_ they all have the same "visual weight", and no in-built intuitions. Try writing up some examples mixing it with different operators, and I think that, no matter what the name is, they all look like they should bind the same way:
>
>
>     1 * 2 `plus` 3 * 4 == plus(1*2, 3*4), not 1 * plus(2, 3) * 4
>     1 + 2 `times` 3 + 4 == times(1+2, 3+4), not 1 + times(2, 3) + 4
>
> … or …
>
>     1 < 2 `plus` 3 == 1 < plus(2, 3), not plus(1<2, 3)
>
>     1 < 2 `times` 3 == 1 < times(2, 3)
>
> You can argue about what exactly the precedence should be, but whatever it is, I'm convinced it should be fixed.
>
> (In Haskell, there's a default, but it's customizable. And people do create little one-letter functions and infix them with custom precedence and convince themselves that `p` looks like it belongs at a different level than `g`, but I think that's silly in Haskell, and would be even more so in Python.)
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/



More information about the Python-ideas mailing list