How is %>% pronounced?

dplyr
teaching

#1

I think a while back I tweeted to @hadley asking him how “%>%” is pronounced when reading code. I can’t seem to find that tweet.

I’m going to be running a training on the tidyverse soon, and will be reading a lot of code out loud.

I think Hadley said that he reads the pipe operator as “then”. But I’m not sure, and thought to ask.


Pronunciations of common R terms
#2

He did.
In French-speaking countries it is puis etc.


#3

I think my internal monologue is stuck with “pipe”. In context, x %>% y is “x piped to y”. I’m not sure that I could switch to “then”, given some old-school BASIC roots, supplemented by an occasional period of VBA programming under duress.


#4

I say the piping operator pipes data from one step to the next, and then make a MONIAC metaphor


#5

Ceci n’est pas un pipe.

The magrittr (to be pronounced with a sophisticated french accent) is a package with two aims: to decrease development time and to improve readability and maintainability of code. Or even shortr: to make your code smokin’ (puff puff)!

(via) https://cran.r-project.org/web/packages/magrittr/vignettes/magrittr.html

So, the answer is pipe/then (pronounced with a sophisticated french accent). :slight_smile:

Or as @hadley & @garrett wrote:

This is my favourite form, because it focusses on verbs, not nouns. You can read this series of function compositions like it’s a set of imperative actions. Foo Foo hops, then scoops, then bops. The downside, of course, is that you need to be familiar with the pipe. If you’ve never seen %>% before, you’ll have no idea what this code does. Fortunately, most people pick up the idea very quickly, so when you share you code with others who aren’t familiar with the pipe, you can easily teach them.

The pipe works by performing a “lexical transformation”: behind the scenes, magrittr reassembles the code in the pipe to a form that works by overwriting an intermediate object.

(via) 18.2.4 @ Wickham, H., Grolemund, G.: R for Data Science (http://r4ds.had.co.nz/pipes.html)


#6

The creator of magrittr also paraphrases the pipe as then. That’s how I teach it as well.


#7

I pronounce it as English pipe during the class (they both in Russian and in English). Sometimes I say word конвейер ‘pipeline’. So we borrowed it as pipe and pronounce it in English way. The same word stands for Unix |.


#8

I (independently of this) came up with “take dataframe and then…” (with some theatrical drawing of breath during long sequences of pipes).


#9

I like the idea of “and then”. Less confusion in my head with “if… then”.


#10

that’s a good point.


#11

Confusion with “if then” was my first thought as well. I would keep with “pipe”. It’s not a hard concept regardless of what it is called, and should someone later have a question, Googling “r pipe” will be significantly more effect than “r then”


#12

Plus, “pipe” has a nice semantic meaning of its own. It sounds a bit more “physical” and emphasizes what you’re actually doing - plopping the output from the prior step into the first argument of the next functions


#13

Okay, maybe we’re getting bogged down on how to pronounce the pipe in different contexts.

To summarize: The symbol %>% is called the pipe and it pipes data and chains of them are called pipelines. But we can also say it as “then” when reading the code aloud. x %>% sort() %>% round() can be read as take x then sort it then round it.


#14

This is what I do: I call %>% the pipe, and pronounce it as “then” when reading a piepline.


#15

Same here, although I’m experimenting with introducing %>% as “the pipe operator”, and later shortening it to “the pipe.” It could be my imagination, but those who hear seem to pick up that “the pipe operator” operates on the things beside it, like, say, the addition operator.

Also, I tend to say “and then” when reading pipelines. Long pipelines should sound like a scene from Dude, Where’s my car? :slight_smile:


#16

My rationale for not using “and then” (and favoring then) is that sometimes pipelines are lazily evaluated, so it’s not a given that the LHS is evaluated before executing the RHS. “And” implies to me that the LHS has been evaluated, while a bare “then” just implies sequence.


#17

:joy: I will never speak a pipeline without thinking of this again!


#18