12 Base types

12.1 Introduction

To talk about objects and OOP in R we first need to clear up a fundamental confusion about two uses of the word “object”. So far in this book, we’ve used the word in the general sense captured by John Chambers’ pithy quote: “Everything that exists in R is an object”. However, while everything is an object, not everything is object-oriented. This confusion arises because the base objects come from S, and were developed before anyone thought that S might need an OOP system. The tools and nomenclature evolved organically over many years without a single guiding principle.

Most of the time, the distinction between objects and object-oriented objects is not important. But here we need to get into the nitty gritty details so we’ll use the terms base objects and OO objects to distinguish them.


  • Section 12.2 shows you how to identify base and OO objects.

  • Section 12.3 gives a complete set of the base types used to build all objects.

12.2 Base versus OO objects

To tell the difference between a base and OO object, use is.object() or sloop::otype():

# A base object:
#> [1] FALSE
#> [1] "base"

# An OO object
#> [1] TRUE
#> [1] "S3"

Technically, the difference between base and OO objects is that OO objects have a “class” attribute:

attr(1:10, "class")

attr(mtcars, "class")
#> [1] "data.frame"

You may already be familiar with the class() function. This function is safe to apply to S3 and S4 objects, but it returns misleading results when applied to base objects. It’s safer to use sloop::s3_class(), which returns the implicit class that the S3 and S4 systems will use to pick methods. You’ll learn more about s3_class() in Section 13.7.1.

x <- matrix(1:4, nrow = 2)
#> [1] "matrix" "array"
#> [1] "matrix"  "integer" "numeric"

12.3 Base types

While only OO objects have a class attribute, every object has a base type:

#> [1] "integer"

#> [1] "list"

Base types do not form an OOP system because functions that behave differently for different base types are primarily written in C code that uses switch statements. This means that only R-core can create new types, and creating a new type is a lot of work because every switch statement needs to be modified to handle a new case. As a consequence, new base types are rarely added. The most recent change, in 2011, added two exotic types that you never see in R itself, but are needed for diagnosing memory problems. Prior to that, the last type added was a special base type for S4 objects added in 2005.

In total, there are 25 different base types. They are listed below, loosely grouped according to where they’re discussed in this book. These types are most important in C code, so you’ll often see them called by their C type names. I’ve included those in parentheses.

  • Vectors, Chapter 3, include types NULL (NILSXP), logical (LGLSXP), integer (INTSXP), double (REALSXP), complex (CPLXSXP), character (STRSXP), list (VECSXP), and raw (RAWSXP).

    #> [1] "NULL"
    #> [1] "integer"
    #> [1] "complex"
  • Functions, Chapter 6, include types closure (regular R functions, CLOSXP), special (internal functions, SPECIALSXP), and builtin (primitive functions, BUILTINSXP).

    #> [1] "closure"
    #> [1] "special"
    #> [1] "builtin"

    Internal and primitive functions are described in Section 6.2.2.

  • Environments, Chapter 7, have type environment (ENVSXP).

    #> [1] "environment"
  • The S4 type (S4SXP), Chapter 15, is used for S4 classes that don’t inherit from an existing base type.

    mle_obj <- stats4::mle(function(x = 1) (x - 2) ^ 2)
    #> [1] "S4"
  • Language components, Chapter 18, include symbol (aka name, SYMSXP), language (usually called calls, LANGSXP), and pairlist (used for function arguments, LISTSXP) types.

    #> [1] "symbol"
    typeof(quote(a + 1))
    #> [1] "language"
    #> [1] "pairlist"

    expression (EXPRSXP) is a special purpose type that’s only returned by parse() and expression(). Expressions are generally not needed in user code.

  • The remaining types are esoteric and rarely seen in R. They are important primarily for C code: externalptr (EXTPTRSXP), weakref (WEAKREFSXP), bytecode (BCODESXP), promise (PROMSXP), ... (DOTSXP), and any (ANYSXP).

You may have heard of mode() and storage.mode(). Do not use these functions: they exist only to provide type names that are compatible with S.

12.3.1 Numeric type

Be careful when talking about the numeric type, because R uses “numeric” to mean three slightly different things:

  1. In some places numeric is used as an alias for the double type. For example as.numeric() is identical to as.double(), and numeric() is identical to double().

    (R also occasionally uses real instead of double; NA_real_ is the one place that you’re likely to encounter this in practice.)

  2. In the S3 and S4 systems, numeric is used as a shorthand for either integer or double type, and is used when picking methods:

    #> [1] "double"  "numeric"
    #> [1] "integer" "numeric"
  3. is.numeric() tests for objects that behave like numbers. For example, factors have type “integer” but don’t behave like numbers (i.e. it doesn’t make sense to take the mean of factor).

    #> [1] "integer"
    #> [1] FALSE

In this book, I consistently use numeric to mean an object of type integer or double.