From @nto|ne@|@br| @end|ng |rom gm@||@com  Sat Oct  5 19:14:32 2019
From: @nto|ne@|@br| @end|ng |rom gm@||@com (Ant F)
Date: Sat, 5 Oct 2019 19:14:32 +0200
Subject: [Rd] should base R have a piping operator ?
In-Reply-To: <ce629286-825e-0315-4570-28c1c57dbfc0@sapo.pt>
References: <CAEKh8uidcEWA4tzmkpQxpF=q7r93qjf-HtiWLfbT91TFGOSzFQ@mail.gmail.com>
 <859F02FC-2DCF-4FFA-A941-1A7285B5F362@win-vector.com>
 <CAEKh8uj_NsmKQcCge1oi0qp3j2AgCV3krMhGiKghmySfKPL=YA@mail.gmail.com>
 <ce629286-825e-0315-4570-28c1c57dbfc0@sapo.pt>
Message-ID: <CAEKh8uj3xG_Y5wV7a1jH15227H4JO=GNqgKc+382Xu+A28Ci-w@mail.gmail.com>

Hi Rui,

> R is a functional language, pipes are not. There are even higher order
functions such as [1] and [2].

If they can be build in R, either R is not a functional language, or pipes
are part of a functional language. Could you elaborate ?
What point would you make against pipes that you couldn't make about other
operators or functions leveraging lazy evaluation ?
I don't understand either the references to Negate() and Recall().

I actually think that there are few things more "functional" than using
pipes :).

> Besides, packages are part of R, R couldn't live without them. I find
> pipes a good idea but I also find it better not to have them as part of
> base R. If you want to use them, load a package, if you don't, don't.
> This simple.

Simple enough, but more complicated than necessary.
I believe it's a fair argument to point than pipes are different. They
don't DO anything and yet are used by thousands of packages.
They are largely viewed as part of R and some users are surprised no to
find them in base R, in the remaining users many don't
even know that they come from magrittr but think they come from dplyr.

The fact that it feels odd to attach a package only to use the pipe is
highlighted by the fact that thousands of packages reexport it
, see https://github.com/search?q=filename%3Autils-pipe.R+magrittr . I
don't think it can be said of any other function.

Package developers could still use `usethis::use_pipe()` if they want to
associate their package
with magrittr's pipe, but they wouldn't "need" it to suggest to user than
piping is recommend way of using their functions in sequence,
and this would mean less red ink saying that this `%>%` pipe was masked by
that other `%>%` pipe.

I like the design of magrittr's pipe a lot and I'd continue to use it
either way, but I would write documentation and even functions with `%.%`
if it was available,
without worrying about dependencies, and less worried about suboptimal
performance.

Best regards,

Antoine










Le sam. 5 oct. 2019 ? 18:03, Rui Barradas <ruipbarradas at sapo.pt> a ?crit :

> Hello,
>
> R is a functional language, pipes are not. There are even higher order
> functions such as [1] and [2].
> Besides, packages are part of R, R couldn't live without them. I find
> pipes a good idea but I also find it better not to have them as part of
> base R. If you want to use them, load a package, if you don't, don't.
> This simple.
>
> As for your example, compose, there is a StackOverflow question on it.
> See this answer [3].
>
> [1] https://stat.ethz.ch/R-manual/R-devel/library/base/html/funprog.html
> [2] https://stat.ethz.ch/R-manual/R-devel/library/base/html/Recall.html
> [3] https://stackoverflow.com/a/52465956/8245406
>
> Hope this helps,
>
> Rui Barradas
>
> ?s 16:48 de 05/10/19, Ant F escreveu:
> > Hi John,
> >
> > Thanks, but the Bizzaro pipe comes with many flaws though :
> > * It's not a single operator
> > * It has a different precedence
> > * It cannot be used in a subcall
> > * The variable assigned to must be on the right
> > * It doesn't trigger indentation when going to the line
> > * It creates/overwrite a `.` variable in the worksace.
> >
> > And it doesn't deal gracefully with some lazy evaluation edge cases such
> as
> > :
> >
> > compose <- function(f, g) { function(x) g(f(x)) }
> > plus1   <- function(x) x + 1
> >
> > plus2 <- plus1 %.% compose(.,plus1)
> > plus2(5)
> > #> [1] 7
> >
> > plus1 ->.; compose(.,plus1) -> .; . -> plus2
> > plus2(5)
> > #> Error: C stack usage  15923776 is too close to the limit
> >
> > What I propose on the other hand can always substitute any existing
> proper
> > pipe in their standard feature, as long as the dot is made explicit.
> >
> > Best regards,
> >
> > Antoine
> >
> >
> >
> > Le sam. 5 oct. 2019 ? 16:59, John Mount <jmount at win-vector.com> a ?crit
> :
> >
> >> Actually, base R already has a pipe fairly close to the one you
> describe:
> >> ->.;
> >>
> >> iris ->.; head(.) ->.; dim(.)
> >> # [1] 6 5
> >>
> >> I've called it the Bizarro pipe (
> >> http://www.win-vector.com/blog/2016/12/magrittrs-doppelganger/ ), and
> for
> >> some reason we chickened out and didn't spend time on it in the dot pipe
> >> paper (
> https://journal.r-project.org/archive/2018/RJ-2018-042/index.html
> >>   ).
> >>
> >> For documentation Bizarro pipe has the advantage that one can work out
> how
> >> it works from the application itself, with out reference to a defining
> >> function.
> >>
> >> On Oct 5, 2019, at 7:34 AM, Ant F <antoine.fabri at gmail.com> wrote:
> >>
> >> Dear R-devel,
> >>
> >> The most popular piping operator sits in the package `magrittr` and is
> used
> >> by a huge amount of users, and imported /reexported by more and more
> >> packages too.
> >>
> >> Many workflows don't even make much sense without pipes nowadays, so the
> >> examples in the doc will use pipes, as do the README, vignettes etc. I
> >> believe base R could have a piping operator so packages can use a pipe
> in
> >> their code or doc and stay dependency free.
> >>
> >> I don't suggest an operator based on complex heuristics, instead I
> suggest
> >> a very simple and fast one (>10 times than magrittr in my tests) :
> >>
> >> `%.%` <- function (e1, e2) {
> >>   eval(substitute(e2), envir = list(. = e1), enclos = parent.frame())
> >> }
> >>
> >> iris %.% head(.) %.% dim(.)
> >> #> [1] 6 5
> >>
> >> The difference with magrittr is that the dots must all be explicit
> (which
> >> sits with the choice of the name), and that special magrittr features
> such
> >> as assignment in place and building functions with `. %>% head() %>%
> dim()`
> >> are not supported.
> >>
> >> Edge cases are not surprising:
> >>
> >> ```
> >> x <- "a"
> >> x %.% quote(.)
> >> #> .
> >> x %.% substitute(.)
> >> #> [1] "a"
> >>
> >> f1 <- function(y) function() eval(quote(y))
> >> f2 <- x %.% f1(.)
> >> f2()
> >> #> [1] "a"
> >> ```
> >>
> >> Looking forward for your thoughts on this,
> >>
> >> Antoine
> >>
> >> [[alternative HTML version deleted]]
> >>
> >> ______________________________________________
> >> R-devel at r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-devel
> >>
> >>
> >> ---------------
> >> John Mount
> >> http://www.win-vector.com/
> >> Our book: Practical Data Science with R
> >>
> https://www.manning.com/books/practical-data-science-with-r-second-edition
> >> <http://www.manning.com/zumel/>
> >>
> >>
> >>
> >>
> >>
> >
> >       [[alternative HTML version deleted]]
> >
> > ______________________________________________
> > R-devel at r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>

	[[alternative HTML version deleted]]



[Rd] should base R have a piping operator ?
Ant F