What is the correct way to put quoted strings in rlang functions?
up vote
0
down vote
favorite
I am writing a fuction that I will use regularly to filter for dates and names in our database (and then to perform some monthly counting/calculations on them).
I would like to know what is the correct way to insert and evaluate strings within rlang
functions in this case?
Am I doing right by using quo
to put strings into the fuction?
Example:
business_flights = tibble(passanger_name=rep(c(rep("John RED",3),rep("Mary ORANGE",3)),4),
dep_date=seq(from = lubridate::ymd('2005-04-07'),
to = lubridate::ymd('2025-03-22'), length.out = 24),
flight_num = sample(seq(from = 99, to = 1999, by = 30), size = 24, replace = TRUE))
filter_flights = function(mytibble, name, date0, date1)
require(tidyverse); require(lubridate)
flights_filtered = mytibble %>%
filter(dep_date >= !!date0, dep_date < !!date1,
grepl(!!name, passanger_name))
View(flights_filtered)
filter_flights(mytibble = business_flights,
name = quo("RED"),
date0 = quo("2005-10-13"),
date1 = quo(today()))
r dplyr tidyverse lubridate rlang
add a comment |
up vote
0
down vote
favorite
I am writing a fuction that I will use regularly to filter for dates and names in our database (and then to perform some monthly counting/calculations on them).
I would like to know what is the correct way to insert and evaluate strings within rlang
functions in this case?
Am I doing right by using quo
to put strings into the fuction?
Example:
business_flights = tibble(passanger_name=rep(c(rep("John RED",3),rep("Mary ORANGE",3)),4),
dep_date=seq(from = lubridate::ymd('2005-04-07'),
to = lubridate::ymd('2025-03-22'), length.out = 24),
flight_num = sample(seq(from = 99, to = 1999, by = 30), size = 24, replace = TRUE))
filter_flights = function(mytibble, name, date0, date1)
require(tidyverse); require(lubridate)
flights_filtered = mytibble %>%
filter(dep_date >= !!date0, dep_date < !!date1,
grepl(!!name, passanger_name))
View(flights_filtered)
filter_flights(mytibble = business_flights,
name = quo("RED"),
date0 = quo("2005-10-13"),
date1 = quo(today()))
r dplyr tidyverse lubridate rlang
1
Why do you want to usequo
? it works fine without it
– Moody_Mudskipper
Nov 10 at 13:20
To go one step further from @Moody_Mudskipper, I dont think you need any quasiquotaton in your example. if you take out bothquo
and!!
, you will get the same result. If you passed a variable that you would want to filter instead ofdep_date
then you would need QQ or use the NSE escape hatches
– Jrakru56
Nov 10 at 16:19
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I am writing a fuction that I will use regularly to filter for dates and names in our database (and then to perform some monthly counting/calculations on them).
I would like to know what is the correct way to insert and evaluate strings within rlang
functions in this case?
Am I doing right by using quo
to put strings into the fuction?
Example:
business_flights = tibble(passanger_name=rep(c(rep("John RED",3),rep("Mary ORANGE",3)),4),
dep_date=seq(from = lubridate::ymd('2005-04-07'),
to = lubridate::ymd('2025-03-22'), length.out = 24),
flight_num = sample(seq(from = 99, to = 1999, by = 30), size = 24, replace = TRUE))
filter_flights = function(mytibble, name, date0, date1)
require(tidyverse); require(lubridate)
flights_filtered = mytibble %>%
filter(dep_date >= !!date0, dep_date < !!date1,
grepl(!!name, passanger_name))
View(flights_filtered)
filter_flights(mytibble = business_flights,
name = quo("RED"),
date0 = quo("2005-10-13"),
date1 = quo(today()))
r dplyr tidyverse lubridate rlang
I am writing a fuction that I will use regularly to filter for dates and names in our database (and then to perform some monthly counting/calculations on them).
I would like to know what is the correct way to insert and evaluate strings within rlang
functions in this case?
Am I doing right by using quo
to put strings into the fuction?
Example:
business_flights = tibble(passanger_name=rep(c(rep("John RED",3),rep("Mary ORANGE",3)),4),
dep_date=seq(from = lubridate::ymd('2005-04-07'),
to = lubridate::ymd('2025-03-22'), length.out = 24),
flight_num = sample(seq(from = 99, to = 1999, by = 30), size = 24, replace = TRUE))
filter_flights = function(mytibble, name, date0, date1)
require(tidyverse); require(lubridate)
flights_filtered = mytibble %>%
filter(dep_date >= !!date0, dep_date < !!date1,
grepl(!!name, passanger_name))
View(flights_filtered)
filter_flights(mytibble = business_flights,
name = quo("RED"),
date0 = quo("2005-10-13"),
date1 = quo(today()))
r dplyr tidyverse lubridate rlang
r dplyr tidyverse lubridate rlang
edited Nov 10 at 12:13
asked Nov 10 at 12:08
lim-lim
123
123
1
Why do you want to usequo
? it works fine without it
– Moody_Mudskipper
Nov 10 at 13:20
To go one step further from @Moody_Mudskipper, I dont think you need any quasiquotaton in your example. if you take out bothquo
and!!
, you will get the same result. If you passed a variable that you would want to filter instead ofdep_date
then you would need QQ or use the NSE escape hatches
– Jrakru56
Nov 10 at 16:19
add a comment |
1
Why do you want to usequo
? it works fine without it
– Moody_Mudskipper
Nov 10 at 13:20
To go one step further from @Moody_Mudskipper, I dont think you need any quasiquotaton in your example. if you take out bothquo
and!!
, you will get the same result. If you passed a variable that you would want to filter instead ofdep_date
then you would need QQ or use the NSE escape hatches
– Jrakru56
Nov 10 at 16:19
1
1
Why do you want to use
quo
? it works fine without it– Moody_Mudskipper
Nov 10 at 13:20
Why do you want to use
quo
? it works fine without it– Moody_Mudskipper
Nov 10 at 13:20
To go one step further from @Moody_Mudskipper, I dont think you need any quasiquotaton in your example. if you take out both
quo
and !!
, you will get the same result. If you passed a variable that you would want to filter instead of dep_date
then you would need QQ or use the NSE escape hatches– Jrakru56
Nov 10 at 16:19
To go one step further from @Moody_Mudskipper, I dont think you need any quasiquotaton in your example. if you take out both
quo
and !!
, you will get the same result. If you passed a variable that you would want to filter instead of dep_date
then you would need QQ or use the NSE escape hatches– Jrakru56
Nov 10 at 16:19
add a comment |
1 Answer
1
active
oldest
votes
up vote
0
down vote
accepted
Non-standard evaluation allows you to capture and manipulate expressions. In base R, this is primarily accomplished through the use of quote
:
quote(x)
# x
quote( a*log10(b+5) )
# a * log10(b + 5)
However, any captured expression that consists of a single literal is itself that literal:
identical( quote(5), 5 ) # TRUE
identical( quote("a"), "a" ) # TRUE
identical( quote(FALSE), FALSE ) # TRUE
identical( quote(5+5), 10 ) # FALSE, expression is not a single literal
rlang::quo
from tidyverse builds on this functionality by capturing an expression AND the environment that gave rise to that expression. Together, these define a quosure:
quo(x)
# <quosure>
# expr: ^x
# env: global
f <- function() quo(x)
f()
# <quosure>
# expr: ^x
# env: 0x55b7e61d5c80
Keeping expressions next to their environments allows you to ensure that they are always evaluated in a consistent fashion, as they make their way through your code:
x <- 5
g <- function( myexpr )
x <- 10
eval_tidy( myexpr )
x # Evaluate expression directly in its environment
# 5
g( quote(x) ) # Evaluate expression inside g()
# 10
g( quo(x) ) # Evaluate expression in its env, while inside g()
# 5
However, when capturing a literal inside a quosure, quo
assigns an empty environment to it:
quo("x")
# <quosure>
# expr: ^"x"
# env: empty
That is because the string "x"
will always evaluate to "x"
, regardless of what environment it's evaluated in. Because of this, there is almost never a good reason to quo
a string object (or any literal for that matter). It doesn't do anything and, as pointed out in the comments, your code will work fine without it.
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
accepted
Non-standard evaluation allows you to capture and manipulate expressions. In base R, this is primarily accomplished through the use of quote
:
quote(x)
# x
quote( a*log10(b+5) )
# a * log10(b + 5)
However, any captured expression that consists of a single literal is itself that literal:
identical( quote(5), 5 ) # TRUE
identical( quote("a"), "a" ) # TRUE
identical( quote(FALSE), FALSE ) # TRUE
identical( quote(5+5), 10 ) # FALSE, expression is not a single literal
rlang::quo
from tidyverse builds on this functionality by capturing an expression AND the environment that gave rise to that expression. Together, these define a quosure:
quo(x)
# <quosure>
# expr: ^x
# env: global
f <- function() quo(x)
f()
# <quosure>
# expr: ^x
# env: 0x55b7e61d5c80
Keeping expressions next to their environments allows you to ensure that they are always evaluated in a consistent fashion, as they make their way through your code:
x <- 5
g <- function( myexpr )
x <- 10
eval_tidy( myexpr )
x # Evaluate expression directly in its environment
# 5
g( quote(x) ) # Evaluate expression inside g()
# 10
g( quo(x) ) # Evaluate expression in its env, while inside g()
# 5
However, when capturing a literal inside a quosure, quo
assigns an empty environment to it:
quo("x")
# <quosure>
# expr: ^"x"
# env: empty
That is because the string "x"
will always evaluate to "x"
, regardless of what environment it's evaluated in. Because of this, there is almost never a good reason to quo
a string object (or any literal for that matter). It doesn't do anything and, as pointed out in the comments, your code will work fine without it.
add a comment |
up vote
0
down vote
accepted
Non-standard evaluation allows you to capture and manipulate expressions. In base R, this is primarily accomplished through the use of quote
:
quote(x)
# x
quote( a*log10(b+5) )
# a * log10(b + 5)
However, any captured expression that consists of a single literal is itself that literal:
identical( quote(5), 5 ) # TRUE
identical( quote("a"), "a" ) # TRUE
identical( quote(FALSE), FALSE ) # TRUE
identical( quote(5+5), 10 ) # FALSE, expression is not a single literal
rlang::quo
from tidyverse builds on this functionality by capturing an expression AND the environment that gave rise to that expression. Together, these define a quosure:
quo(x)
# <quosure>
# expr: ^x
# env: global
f <- function() quo(x)
f()
# <quosure>
# expr: ^x
# env: 0x55b7e61d5c80
Keeping expressions next to their environments allows you to ensure that they are always evaluated in a consistent fashion, as they make their way through your code:
x <- 5
g <- function( myexpr )
x <- 10
eval_tidy( myexpr )
x # Evaluate expression directly in its environment
# 5
g( quote(x) ) # Evaluate expression inside g()
# 10
g( quo(x) ) # Evaluate expression in its env, while inside g()
# 5
However, when capturing a literal inside a quosure, quo
assigns an empty environment to it:
quo("x")
# <quosure>
# expr: ^"x"
# env: empty
That is because the string "x"
will always evaluate to "x"
, regardless of what environment it's evaluated in. Because of this, there is almost never a good reason to quo
a string object (or any literal for that matter). It doesn't do anything and, as pointed out in the comments, your code will work fine without it.
add a comment |
up vote
0
down vote
accepted
up vote
0
down vote
accepted
Non-standard evaluation allows you to capture and manipulate expressions. In base R, this is primarily accomplished through the use of quote
:
quote(x)
# x
quote( a*log10(b+5) )
# a * log10(b + 5)
However, any captured expression that consists of a single literal is itself that literal:
identical( quote(5), 5 ) # TRUE
identical( quote("a"), "a" ) # TRUE
identical( quote(FALSE), FALSE ) # TRUE
identical( quote(5+5), 10 ) # FALSE, expression is not a single literal
rlang::quo
from tidyverse builds on this functionality by capturing an expression AND the environment that gave rise to that expression. Together, these define a quosure:
quo(x)
# <quosure>
# expr: ^x
# env: global
f <- function() quo(x)
f()
# <quosure>
# expr: ^x
# env: 0x55b7e61d5c80
Keeping expressions next to their environments allows you to ensure that they are always evaluated in a consistent fashion, as they make their way through your code:
x <- 5
g <- function( myexpr )
x <- 10
eval_tidy( myexpr )
x # Evaluate expression directly in its environment
# 5
g( quote(x) ) # Evaluate expression inside g()
# 10
g( quo(x) ) # Evaluate expression in its env, while inside g()
# 5
However, when capturing a literal inside a quosure, quo
assigns an empty environment to it:
quo("x")
# <quosure>
# expr: ^"x"
# env: empty
That is because the string "x"
will always evaluate to "x"
, regardless of what environment it's evaluated in. Because of this, there is almost never a good reason to quo
a string object (or any literal for that matter). It doesn't do anything and, as pointed out in the comments, your code will work fine without it.
Non-standard evaluation allows you to capture and manipulate expressions. In base R, this is primarily accomplished through the use of quote
:
quote(x)
# x
quote( a*log10(b+5) )
# a * log10(b + 5)
However, any captured expression that consists of a single literal is itself that literal:
identical( quote(5), 5 ) # TRUE
identical( quote("a"), "a" ) # TRUE
identical( quote(FALSE), FALSE ) # TRUE
identical( quote(5+5), 10 ) # FALSE, expression is not a single literal
rlang::quo
from tidyverse builds on this functionality by capturing an expression AND the environment that gave rise to that expression. Together, these define a quosure:
quo(x)
# <quosure>
# expr: ^x
# env: global
f <- function() quo(x)
f()
# <quosure>
# expr: ^x
# env: 0x55b7e61d5c80
Keeping expressions next to their environments allows you to ensure that they are always evaluated in a consistent fashion, as they make their way through your code:
x <- 5
g <- function( myexpr )
x <- 10
eval_tidy( myexpr )
x # Evaluate expression directly in its environment
# 5
g( quote(x) ) # Evaluate expression inside g()
# 10
g( quo(x) ) # Evaluate expression in its env, while inside g()
# 5
However, when capturing a literal inside a quosure, quo
assigns an empty environment to it:
quo("x")
# <quosure>
# expr: ^"x"
# env: empty
That is because the string "x"
will always evaluate to "x"
, regardless of what environment it's evaluated in. Because of this, there is almost never a good reason to quo
a string object (or any literal for that matter). It doesn't do anything and, as pointed out in the comments, your code will work fine without it.
answered Nov 16 at 21:13
Artem Sokolov
4,69221936
4,69221936
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53238792%2fwhat-is-the-correct-way-to-put-quoted-strings-in-rlang-functions%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
Why do you want to use
quo
? it works fine without it– Moody_Mudskipper
Nov 10 at 13:20
To go one step further from @Moody_Mudskipper, I dont think you need any quasiquotaton in your example. if you take out both
quo
and!!
, you will get the same result. If you passed a variable that you would want to filter instead ofdep_date
then you would need QQ or use the NSE escape hatches– Jrakru56
Nov 10 at 16:19