Someone asked recently how lambda.r deals with NAs in type constraints. Type constraints are optional decorations on a function that enforces the type for each function argument. The short answer is that since NAs are typed, they work just like other values.

Consider the toy function

f(x) %::% numeric : numeric
f(x) %as% x^2

Calling f with a vector containing NAs works as expected:

> f(c(1,2,3,NA,5))
[1]  1  4  9 NA 25

What happens if you pass a scalar NA? Now things get interesting.

> f(NA)
Error in UseFunction(f, "f", ...) : No valid function for 'f(logical)'

Lo, we get an error! This is an artifact of how R deals with NA values. Since NAs are typed, normally the type can be inferred by the other values in a vector. However, if NA is the only value i.e. a scalar, no information is available. Therefore R must choose some default value, which happens to be logical.

> class(NA)
[1] "logical"

To get around this situation, one can simply use the explicitly typed NA constant for the type you care about. In this case, it’s NA_integer_.

> f(NA_integer_)
[1] NA

See ?NA for more information on the mechanics and behavior of NA.

lambda.r is available on CRAN. The most recent version is on github and can be installed using devtools:

library(devtools)
install_github('lambda.r','zatonovo')