[Python-ideas] (no subject)

[Andrew Barnert]

On May 6, 2015, at 18:13, Stephen J. Turnbull <stephen at xemacs.org> wrote:
> 
> Ivan Levkivskyi writes:
> 
>> Ok, I will try inspecting all existing approaches to find the one
>> that seems more "right" to me :)
> 
> If you do inspect all the approaches you can find, I hope you'll keep
> notes and publish them, perhaps as a blog article.
> 
>> In any case that approach could be updated by incorporating matrix
>> @ as a dedicated operator for compositions.
> 
> I think rather than "dedicated" you mean "suggested".  One of Andrew's
> main points is that you're unlikely to find more than a small minority
> agreeing on the "right" approach, no matter which one you choose.

Whatever wording you use, I do think it's likely that at least some of the existing libraries would become much more readable just by using @ in place of what they currently use. Even better,
It may also turn out that the @ notation just "feels right" with one solution to the argument problem and wrong with another, narrowing down the possibility space.

So, I think it's definitely worth pushing the experiments if someone has the time and inclination, so I'm glad Ivan has volunteered.

>> At least, it seems that Erik from astropy likes this idea and it is
>> quite natural for people with "scientific" background.

I forgot to say before, but: it's great to have input from people coming from the MATLAB-y scientific/numeric world like him (I think) rather than just the Haskell/ML-y mathematical/CS world like you (Stephen, I think), as we usually get in these discussions. If there's one option that's universally obviously right to everyone in the first group, maybe everyone in the second group can shut up and deal with it. If not (which I think is likely, but I'll keep an open mind), well, at least we've got broader viewpoints and more data for Ivan's summary.

> Sure, but as he also points out, when you know that you're going to be
> composing only functions of one argument, the Unix pipe symbol is also
> quite natural (as is Haskell's operator-less notation).  While one of
> my hobbies is category theory (basically, the mathematical theory of
> composable maps for those not familiar with the term), I find the Unix
> pipeline somehow easier to think about than abstract composition,
> although I believe they're equivalent (at least as composition is
> modeled by category theory).

I think you're right that they're equivalent in theory.

But I feel like they're also equivalent in usability and readability (as in for 1/3 simple cases they're both fine, for 1/3 compose looks better, for 1/3 rcompose), but I definitely can't argue for that.

What always throws me is that most languages that offer both choose different precedence (and sometimes associativity, too) for them. The consequence seems to be that when I just use compose and rcompose operators without thinking about it, I always get them right, but as soon as I ask myself "which one is like shell pipes?" or "why did I put parens here?" I get confused and have to go take a break before I can write any more code. Haskell's operatorless notation is nice because it prevents me from noticing what I'm doing and asking myself those questions. :)