How to avoid piping to first argument? about magrittr HOT 7 CLOSED

The CRAN version does not have support for nested dots.
In the GitHub version we are currently working with semantics where LHS is piped as first argument if there are no dots at the first level, although this is not a guarantee that this is how the next formal version will work.

In many real use cases (I am not really considering the above point, which valid but somewhat artificial, to be a common use case) treating first-level dots separately is often advantageous.

For example

iris %>%
    extract(3, 100:nrow(.))

is IMO clearner and easier to read than

iris %>%
    extract(., 3, 100:nrow(.))

Most often, in my experience, the use of nested dots is secondary in the sense that one is after an attribute of some sort, length, nrow, colnames, etc, and when this is the case the current syntax gives cleaner code.

Another more subtle example is

1:10 %>% paste(., .)

versus

1:10 %>% paste((.))

Since you are pasting one thing together with 1:10 (itself) then you can argue that nr. 2 is more expressive.

Also a few prominent packages, e.g. dplyr, design their functions with%>%in mind, and the argument used forextractabove carries through to all the verbs likefilter,mutate,summarize,group_by`, etc. That extra dot is more often an inconvenience than not.

Surely @runken-ken 's example above is valid, but really sort of uninteresting. A lot of the other examples you give in your blog post are also uninteresting, say

1:10 %>% f(length(.), length(.))

Here you should write

1:10 %>% length %>% f(., .)

All that said, none of this is final, and @runken-ken you are "making fun" of a development version in your blog; you might want to mention that.

from magrittr.

@renkun-ken I am not sure which magrittr version you used. For the CRAN package both of your examples fail for me. For the most recent github version only the second one fails. I guess you have an old version from github, maybe?

from magrittr.

Thanks for you answers. These are only demo cases which are poorly designed but largely represent how users I know think or believe how it will work and find it does not work as supposed.

A user would not do stupid things like f(length(.), length(.)) but f(min(.), max(.)) and think it is natural and should magically work.

from magrittr.

This post might help here.
renkun-ken/pipeR#18

from magrittr.

Suppose a user receives some code like:

...
ab <- obj1 %>% length %>% f(min(.), max(.))
...

If the user is not very familiar with how magrittr works, he or she won't be able to figure out what is going to happen before running the code. If the object is mistakenly piped to some function with default arguments, it would be a nightmare to find the bug. That's why I think experience-based rules of piping can be a fatal defect of magrittr used in large and complex code. It perfectly works for interactive analysis with ordinary functions in experience, but for more complex environment and more various demands, I feel quite unsafe about it.

from magrittr.

I believe it would be better for the community to produce readable and, more importantly, non-ambiguous code. My suggestion is that magrittr should clearly and explicitly define its piping rules or otherwise it will give users false belief until one day they find it wrong or does not work as supposed.

from magrittr.

I personally like the "no nested dots" rule, as it is currently in the CRAN version. I like its simplicity and that I don't have to think hard about how the pipes are connected. When I write code, I am already thinking hard about the problem I want to solve, and thinking hard about one thing hurts already.

Of course I don't mind having the nested dot functionality in magrittr, I will just not use it. :) Although other people will, and I will need to read their code occasionally, so it would still be great to keep the no nested dots rule, I think.

from magrittr.