As a matter of fact I played a few days ago with this idea of transforming
the pipe chain to a sequence of calls such as the one Gabriel proposed.
My proposed debugging method was to use a debugging pipe
calling iris %>% head %B>% dim %>% length will open place you right at the
browser call below
On 05/10/2019 7:50 p.m., Gabriel Becker wrote:
Hi all,
I think there's some nuance here that makes makes me agree partially with
each "side".
The pipe is inarguably extremely popular. Many probably think of it as a
core feature of R, along with the tidyverse that (as was pointed out)
largely su
Except for the isolation of local() R pretty much already has the parsing
transformation you mention.
as.list(parse(text="
iris ->.;
group_by(., Species) ->.;
summarize(., mean_sl = mean(Sepal.Length)) ->.;
filter(., mean_sl > 5)
"))
#> [[1]]
#> . <- iris
#>
#> [[2]]
#> . <- group_by
The first of Suharno's examples can be viewed that way, because R under ESS is
not a "slave" in the technical sense, just a situation where you do not want
keyboard input to be echoed. "Non-echoing" might have been better language
though.
The 2nd example really is of the master/slave variety, a
Description of arguments main, xlab, ylab in hist.Rd in current R devel and R
patched ends with this.
the default \code{ylab} is \code{"Frequency"} iff \code{probability} is true
In fact, if 'probability' is true, the histogram doesn't represent frequencies.
It should be
the default \code{ylab}
As far as I know, not being involved with the effort at all, they are
removing the term 'slave' and replacing it with 'no-echo' which is intended
to be fully synonmyous with the meaning of the old 'slave' term.
~G
On Sun, Oct 6, 2019 at 10:56 PM suharto_anggono--- via R-devel <
r-devel@r-project.
SVN revision replaces "slave" with "no-echo" in R devel.
In each of the following, "no-echo" is rather strange to me.
- src/gnuwin32/README.Rterm
3) As a no-echo process for ESS mode in NTEmacs with flag --ess.
- src/library/grDevices/src/qdCocoa.m
/* the no-echo thread work until this is NO */
On Sun, 6 Oct 2019 at 10:30, Joris Meys wrote:
>
> I'm largely with Gabriel Becker on this one: if pipes enter base R, they
> should be a well thought out and integrated part of the language.
>
> I do see merit though in providing a pipe in base R. Reason is mainly that
> right now there's not a s
I'm largely with Gabriel Becker on this one: if pipes enter base R, they
should be a well thought out and integrated part of the language.
I do see merit though in providing a pipe in base R. Reason is mainly that
right now there's not a single pipe. A pipe function exists in different
packages, a
