[R] Implement is.type() functions for dplyr

[asfimport]

Define functions in nse_funcs for all the important base R generic is.type() functions, including:

• is.numeric()

• is.double()

• is.integer()

• is.integer64()

• is.character()

• is.logical()

  Maybe also:

• is.factor() # TRUE for dictionary types

• is.ordered() # TRUE for ordered dictionary types

• is.list() # TRUE for ListArrays

  I think the easiest way to implement this would be to check $type_id() against the Type enum values, for example:

  array$type_id() %in% Type[c("UINT8", "INT8", ...)]

  For this to work the same way on unevaluated Expression columns in arrow_dplyr_query objects, add a public function type_id() to the Expression R6 class like this:

  type_id = function(schema) compute___expr__type(self, schema)$id,

Reporter: Ian Cook / @ianmcook
Assignee: Ian Cook / @ianmcook

Related issues:

• [R] Support tidyselect where() selection helper in dplyr verbs (is depended upon by)

PRs and other links:

• GitHub Pull Request #10327

_{Note: This issue was originally created as ARROW-12781. Please see the migration documentation for further details.}

[asfimport]

Ian Cook / @ianmcook:
@nealrichardson  what do you think about whether these should be defined as ArrowDatum methods or only defined in nse_funcs?

[asfimport]

Ian Cook / @ianmcook:
Hmm, it looks like for this to work on Expression objects, we also need to pass the schema to the $type() method. I'm not sure how exactly we would do that but it would certainly not work outside of the dplyr context.

[asfimport]

Neal Richardson / @nealrichardson:
I think we only want them defined in dplyr, and maybe only inside where(). Suppose you defined is.numeric to return TRUE on an Arrow int32() array, and then you call a base R function that has if (is.numeric(var) .... That will probably be ugly.

[asfimport]

Ian Cook / @ianmcook:
Ok, thanks, agreed.

I think it's OK to have them defined for use in dplyr outside of where(), just like the as.<type>() functions are

[asfimport]

Ian Cook / @ianmcook:
Issue resolved by pull request 10327
#10327