R Language Definition ¶

2.1.1 Vectors ¶

Vectors can be thought of as contiguous cells containing data. Cells are accessed through indexing operations such as x[5]. More details are given in Indexing.

A single element of a character vector is often referred to as a character string or short string. ¹

2.1.2 Lists ¶

Lists (“generic vectors”) are another kind of data storage. Lists have elements, each of which can contain any type of R object, i.e. the elements of a list do not have to be of the same type. List elements are accessed through three different indexing operations. These are explained in detail in Indexing.

Lists are vectors, and the basic vector types are referred to as atomic vectors where it is necessary to exclude lists.

2.1.3 Language objects ¶

There are three types of objects that constitute the R language. They are calls, expressions, and names. Since R has objects of type "expression" we will try to avoid the use of the word expression in other contexts. In particular syntactically correct expressions will be referred to as statements.

They can be created directly from expressions using the quote mechanism and converted to and from lists by the as.list and as.call functions. Components of the parse tree can be extracted using the standard indexing operations.

• Symbol objects

2.1.4 Expression objects ¶

In R one can have objects of type "expression". An expression contains one or more statements. A statement is a syntactically correct collection of tokens. Expression objects are special language objects which contain parsed but unevaluated R statements. The main difference is that an expression object can contain several such expressions. Another more subtle difference is that objects of type "expression" are only evaluated when explicitly passed to eval, whereas other language objects may get evaluated in some unexpected cases.

An expression object behaves much like a list and its components should be accessed in the same way as the components of a list.

2.1.5 Function objects ¶

In R functions are objects and can be manipulated in much the same way as any other object. Functions (or more precisely, function closures) have three basic components: a formal argument list, a body and an environment. The argument list is a comma-separated list of arguments. An argument can be a symbol, or a ‘symbol = default’ construct, or the special argument .... The second form of argument is used to specify a default value for an argument. This value will be used if the function is called without any value specified for that argument. The ... argument is special and can contain any number of arguments. It is generally used if the number of arguments is unknown or in cases where the arguments will be passed on to another function.

A function’s environment is the environment that was active at the time that the function was created. Any symbols bound in that environment are captured and available to the function. This combination of the code of the function and the bindings in its environment is called a ‘function closure’, a term from functional programming theory. In this document we generally use the term ‘function’, but use ‘closure’ to emphasize the importance of the attached environment.

It is possible to extract and manipulate the three parts of a closure object using formals, body, and environment constructs (all three can also be used on the left hand side of assignments). The last of these can be used to remove unwanted environment capture.

When a function is called, a new environment (called the evaluation environment) is created, whose enclosure (see Environments) is the environment from the function closure. This new environment is initially populated with the unevaluated arguments to the function; as evaluation proceeds, local variables are created within it.

There is also a facility for converting functions to and from list structures using as.list and as.function. These have been included to provide compatibility with S and their use is discouraged.

2.1.6 NULL ¶

There is a special object called NULL. It is used whenever there is a need to indicate or specify that an object is absent. It should not be confused with a vector or list of zero length.

2.1.7 Builtin objects and special forms ¶

These two kinds of object contain the builtin functions of R, i.e., those that are displayed as .Primitive in code listings (as well as those accessed via the .Internal function and hence not user-visible as objects). The difference between the two lies in the argument handling. Builtin functions have all their arguments evaluated and passed to the internal function, in accordance with call-by-value, whereas special functions pass the unevaluated arguments to the internal function.

From the R language, these objects are just another kind of function. The is.primitive function can distinguish them from interpreted functions.

2.1.8 Promise objects ¶

Promise objects are part of R’s lazy evaluation mechanism. They contain three slots: a value, an expression, and an environment. When a function is called the arguments are matched and then each of the formal arguments is bound to a promise. The expression that was given for that formal argument and a pointer to the environment the function was called from are stored in the promise.

Until that argument is accessed there is no value associated with the promise. When the argument is accessed, the stored expression is evaluated in the stored environment, and the result is returned. The result is also saved by the promise. The substitute function will extract the content of the expression slot. This allows the programmer to access either the value or the expression associated with the promise.

2.1.9 Dot-dot-dot ¶

The ... object type is stored as a type of pairlist. The components of ... can be accessed in the usual pairlist manner from C code, but ... is not easily accessed as an object in interpreted code, and even the existence of such an object should typically not be assumed, as that may change in the future.

The object can be captured (with promises being forced!) as a list, so for example in table one sees

    args <- list(...)
## ....
    for (a in args) {
## ....

Note that the implementation of ... as a pairlist object is not to be considered part of the R API, and code outside base R should not rely on this current description of .... On the other hand, the above list(...) access, and the other “dot-access” functions ...length(), ...elt(), ...names(), and “reserved words” ..1, ..2, etc, see also help page ?dots, are part of the stable R API.

2.1.10 Environments ¶

Environments can be thought of as consisting of two things. A frame, consisting of a set of symbol-value pairs, and an enclosure, a pointer to an enclosing environment. When R looks up the value for a symbol the frame is examined and if a matching symbol is found its value will be returned. If not, the enclosing environment is then accessed and the process repeated. Environments form a tree structure in which the enclosures play the role of parents. The tree of environments is rooted in an empty environment, available through emptyenv(), which has no parent. It is the direct parent of the environment of the base package (available through the baseenv() function).

Environments are created implicitly by function calls, as described in Function objects and Lexical environment. In this case the environment contains the variables local to the function (including the arguments), and its enclosure is the environment of the currently called function. Environments may also be created directly by new.env. The frame content of an environment can be accessed by use of ls, names, $, [, [[, get, and get0, and manipulated by $<-, [[<-, and assign as well as eval and evalq.

2.1.11 Pairlist objects ¶

Pairlist objects are similar to Lisp’s dotted-pair lists. They are used extensively in the internals of R, but are rarely visible in interpreted code, although they are returned by formals, and can be created by (e.g.) the pairlist function. A zero-length pairlist is NULL, as would be expected in Lisp but in contrast to a zero-length list. Each such object has three slots, a CAR value, a CDR value and a TAG value. The TAG value is a text string and CAR and CDR usually represent, respectively, a list item (head) and the remainder (tail) of the list with a NULL object as terminator (the CAR/CDR terminology is traditional Lisp and originally referred to the address and decrement registers on an early 60’s IBM computer).

2.1.12 The “Any” type ¶

It is not really possible for an object to be of “Any” type, but it is nevertheless a valid type value. It gets used in certain (rather rare) circumstances, e.g. as.vector(x, "any"), indicating that type coercion should not be done.

2.2.1 Names ¶

A names attribute, when present, labels the individual elements of a vector or list. When an object is printed the names attribute, when present, is used to label the elements. The names attribute can also be used for indexing purposes, for example, quantile(x)["25%"].

One may get and set the names using names and names<- constructions. The latter will perform the necessary consistency checks to ensure that the names attribute has the proper type and length.

2.2.2 Dimensions ¶

The dim attribute is used to implement arrays. The content of the array is stored in a vector in column-major order and the dim attribute is a vector of integers specifying the respective extents of the array. R ensures that the length of the vector is the product of the lengths of the dimensions. The length of one or more dimensions may be zero.

2.2.3 Dimnames ¶

Arrays may name each dimension separately using the dimnames attribute which is a list of character vectors. The dimnames list may itself have names which are then used for extent headings when printing arrays.

2.2.4 Classes ¶

R has an elaborate class system², principally controlled via the class attribute. This attribute is a character vector containing the list of classes that an object inherits from. This forms the basis of the “generic methods” functionality in R.

This attribute can be accessed and manipulated virtually without restriction by users. There is no checking that an object actually contains the components that class methods expect. Thus, altering the class attribute should be done with caution, and when they are available specific creation and coercion functions should be preferred.

2.2.5 Time series attributes ¶

The tsp attribute is used to hold parameters of time series, start, end, and frequency. This construction is mainly used to handle series with periodic substructure such as monthly or quarterly data.

2.2.6 Copying of attributes ¶

Whether attributes should be copied when an object is altered is a complex area, but there are some general rules (Becker, Chambers & Wilks, 1988, pp. 144–6).

Scalar functions (those which operate element-by-element on a vector and whose output is similar to the input) should preserve attributes (except perhaps class).

Binary operations normally copy most attributes from the longer argument (and if they are of the same length from both, preferring the values on the first). Here ‘most’ means all except the names, dim and dimnames which are set appropriately by the code for the operator.

Subsetting (other than by an empty index) generally drops all attributes except names, dim and dimnames which are reset as appropriate. On the other hand, subassignment generally preserves attributes even if the length is changed. Coercion drops all attributes.

The default method for sorting drops all attributes except names, which are sorted along with the object.

2.3.1 Factors ¶

Factors are used to describe items that can have a finite number of values (gender, social class, etc.). A factor has a levels attribute and class "factor". Optionally, it may also contain a contrasts attribute which controls the parametrisation used when the factor is used in a modeling functions.

2.3.2 Data frame objects ¶

Data frames are the R structures which most closely mimic the SAS or SPSS data set, i.e. a “cases by variables” matrix of data.

A data frame is a list of vectors, factors, and/or matrices all having the same length (number of rows in the case of matrices). In addition, a data frame generally has a names attribute labeling the variables and a row.names attribute for labeling the cases.

A data frame can contain a list that is the same length as the other components. The list can contain elements of differing lengths thereby providing a data structure for ragged arrays. However, as of this writing such arrays are not generally handled correctly.

3.1.1 Constants ¶

Any number typed directly at the prompt is a constant and is evaluated.

> 1
[1] 1

Perhaps unexpectedly, the number returned from the expression 1 is a numeric. In most cases, the difference between an integer and a numeric value will be unimportant as R will do the right thing when using the numbers. There are, however, times when we would like to explicitly create an integer value for a constant. We can do this by calling the function as.integer or using various other techniques. But perhaps the simplest approach is to qualify our constant with the suffix character ‘L’. For example, to create the integer value 1, we might use

> 1L
[1]

We can use the ‘L’ suffix to qualify any number with the intent of making it an explicit integer. So ‘0x10L’ creates the integer value 16 from the hexadecimal representation. The constant 1e3L gives 1000 as an integer rather than a numeric value and is equivalent to 1000L. (Note that the ‘L’ is treated as qualifying the term 1e3 and not the 3.) If we qualify a value with ‘L’ that is not an integer value, e.g. 1e-3L, we get a warning and the numeric value is created. A warning is also created if there is an unnecessary decimal point in the number, e.g. 1.L.

We get a syntax error when using ‘L’ with complex numbers, e.g. 12iL gives an error.

Constants are fairly boring and to do more we need symbols.

3.1.2 Symbol lookup ¶

When a new variable is created it must have a name so it can be referenced and it usually has a value. The name itself is a symbol. When a symbol is evaluated its value is returned. Later we shall explain in detail how to determine the value associated with a symbol.

In this small example y is a symbol and its value is 4. A symbol is an R object too, but one rarely needs to deal with symbols directly, except when doing “programming on the language” (Computing on the language).

> y <- 4
> y
[1] 4

3.1.3 Function calls ¶

Most of the computations carried out in R involve the evaluation of functions. We will also refer to this as function invocation. Functions are invoked by name with a list of arguments separated by commas.

> mean(1:10)
[1] 5.5

A special type of function calls can appear on the left hand side of the assignment operator as in

> class(x) <- "foo"

3.1.4 Operators ¶

R allows the use of arithmetic expressions using operators similar to those of the C programming language, for instance

> 1 + 2
[1] 3

Expressions can be grouped using parentheses, mixed with function calls, and assigned to variables in a straightforward manner

> y <- 2 * (a + log(x))

R contains a number of operators. They are listed in the table below.

Except for the syntax, there is no difference between applying an operator and calling a function. In fact, x + y can equivalently be written `+`(x, y). Notice that since ‘+’ is a non-standard function name, it needs to be quoted.

R deals with entire vectors of data at a time, and most of the elementary operators and basic mathematical functions like log are vectorized (as indicated in the table above). This means that e.g. adding two vectors of the same length will create a vector containing the element-wise sums, implicitly looping over the vector index. This applies also to other operators like -, *, and / as well as to higher dimensional structures. Notice in particular that multiplying two matrices does not produce the usual matrix product (the %*% operator exists for that purpose). Some finer points relating to vectorized operations will be discussed in Elementary arithmetic operations.

To access individual elements of an atomic vector, one generally uses the x[i] construction.

> x <- rnorm(5)
> x
[1] -0.12526937 -0.27961154 -1.03718717 -0.08156527  1.37167090
> x[2]
[1] -0.2796115

List components are more commonly accessed using x$a or x[[i]].

> x <- options()
> x$prompt
[1] "> "

Indexing constructs can also appear on the right hand side of an assignment.

R’s indexing operations contain many advanced features which are further described in Indexing.

3.2.1 if ¶

The if/else statement conditionally evaluates two statements. There is a condition which is evaluated and if the value is TRUE then the first statement is evaluated; otherwise the second statement will be evaluated. The if/else statement returns, as its value, the value of the statement that was selected. The formal syntax is

if ( statement1 )
    statement2
else
    statement3

First, statement1 is evaluated to yield value1. If value1 is a logical vector with first element TRUE then statement2 is evaluated. If the first element of value1 is FALSE then statement3 is evaluated. If value1 is a numeric vector then statement3 is evaluated when the first element of value1 is zero and otherwise statement2 is evaluated. Only the first element of value1 is used. All other elements are ignored. If value1 has any type other than a logical or a numeric vector an error is signalled.

if/else statements can be used to avoid numeric problems such as taking the logarithm of a negative number. Because if/else statements are the same as other statements you can assign the value of them. The two examples below are equivalent.

> if( any(x <= 0) ) y <- log(1+x) else y <- log(x)
> y <- if( any(x <= 0) ) log(1+x) else log(x)

The else clause is optional. The statement if(any(x <= 0)) x <- x[x <= 0] is valid. When the if statement is not in a block the else, if present, must appear on the same line as the end of statement2. Otherwise the new line at the end of statement2 completes the if and yields a syntactically complete statement that is evaluated. A simple solution is to use a compound statement wrapped in braces, putting the else on the same line as the closing brace that marks the end of the statement.

if/else statements can be nested.

if ( statement1 ) {
    statement2
} else if ( statement3 ) {
    statement4
} else if ( statement5 ) {
    statement6
} else
    statement8

One of the even numbered statements will be evaluated and the resulting value returned. If the optional else clause is omitted and all the odd numbered statements evaluate to FALSE no statement will be evaluated and NULL is returned.

The odd numbered statements are evaluated, in order, until one evaluates to TRUE and then the associated even numbered statement is evaluated. In this example, statement6 will only be evaluated if statement1 is FALSE and statement3 is FALSE and statement5 is TRUE. There is no limit to the number of else if clauses that are permitted.

3.2.2 Looping ¶

R has three statements that provide explicit looping.⁴ They are for, while and repeat. The two built-in constructs, next and break, provide additional control over the evaluation. R provides other functions for implicit looping such as tapply, apply, and lapply. In addition many operations, especially arithmetic ones, are vectorized so you may not need to use a loop.

There are two statements that can be used to explicitly control looping. They are break and next. The break statement causes an exit from the innermost loop that is currently being executed. The next statement immediately causes control to return to the start of the loop. The next iteration of the loop (if there is one) is then executed. No statement below next in the current loop is evaluated.

3.2.3 repeat ¶

repeat statement

3.2.4 while ¶

while ( statement1 ) statement2

3.2.5 for ¶

for ( name in vector )
   statement1

3.2.6 switch ¶

switch (statement, list)

> x <- 3
> switch(x, 2+2, mean(1:10), rnorm(5))
[1]  2.2903605  2.3271663 -0.7060073  1.3622045 -0.2892720
> switch(2, 2+2, mean(1:10), rnorm(5))
[1] 5.5
> switch(6, 2+2, mean(1:10), rnorm(5))
NULL

> y <- "fruit"
> switch(y, fruit = "banana", vegetable = "broccoli", "Neither")
[1] "banana"
> y <- "meat"
> switch(y, fruit = "banana", vegetable = "broccoli", "Neither")
[1] "Neither"

> centre <- function(x, type) {
+ switch(type,
+        mean = mean(x),
+        median = median(x),
+        trimmed = mean(x, trim = .1))
+ }
> x <- rcauchy(10)
> centre(x, "mean")
[1] 0.8760325
> centre(x, "median")
[1] 0.5360891
> centre(x, "trimmed")
[1] 0.6086504

3.3.1 Recycling rules ¶

If one tries to add two structures with a different number of elements, then the shortest is recycled to length of longest. That is, if for instance you add c(1, 2, 3) to a six-element vector then you will really add c(1, 2, 3, 1, 2, 3). If the length of the longer vector is not a multiple of the shorter one, a warning is given.

As from R 1.4.0, any arithmetic operation involving a zero-length vector has a zero-length result.

3.3.2 Propagation of names ¶

3.3.3 Dimensional attributes ¶

(matrix+matrix, dimensions must match. vector+matrix: first recycle, then check if dims fit, error if not)

3.3.4 NA handling ¶

Missing values in the statistical sense, that is, variables whose value is not known, have the value NA. This should not be confused with the missing property for a function argument that has not been supplied (see Arguments).

As the elements of an atomic vector must be of the same type there are multiple types of NA values. There is one case where this is particularly important to the user. The default type of NA is logical, unless coerced to some other type, so the appearance of a missing value may trigger logical rather than numeric indexing (see Indexing for details).

Numeric and logical calculations with NA generally return NA. In cases where the result of the operation would be the same for all possible values the NA could take, the operation may return this value. In particular, ‘FALSE & NA’ is FALSE, ‘TRUE | NA’ is TRUE. NA is not equal to any other value or to itself; testing for NA is done using is.na. However, an NA value will match another NA value in match.

Numeric calculations whose result is undefined, such as ‘0/0’, produce the value NaN. This exists only in the double type and for real or imaginary components of the complex type. The function is.nan is provided to check specifically for NaN, is.na also returns TRUE for NaN. Coercing NaN to logical or integer type gives an NA of the appropriate type, but coercion to character gives the string "NaN". NaN values are incomparable so tests of equality or collation involving NaN will result in NA. They are regarded as matching any NaN value (and no other value, not even NA) by match.

3.4.1 Indexing by vectors ¶

R allows some powerful constructions using vectors as indices. We shall discuss indexing of simple vectors first. For simplicity, assume that the expression is x[i]. Then the following possibilities exist according to the type of i.

• Integer. All elements of i must have the same sign. If they are positive, the elements of x with those index numbers are selected. If i contains negative elements, all elements except those indicated are selected.

  If i is positive and exceeds length(x) then the corresponding selection is NA. Negative out of bounds values for i are silently disregarded since R version 2.6.0, S compatibly, as they mean to drop non-existing elements and that is an empty operation (“no-op”).

  A special case is the zero index, which has null effects: x[0] is an empty vector and otherwise including zeros among positive or negative indices has the same effect as if they were omitted.

• Other numeric. Non-integer values are converted to integer (by truncation towards zero) before use.
• Logical. The indexing i should generally have the same length as x. If it is shorter, then its elements will be recycled as discussed in Elementary arithmetic operations. If it is longer, then x is conceptually extended with NAs. The selected values of x are those for which i is TRUE.
• Character. The strings in i are matched against the names attribute of x and the resulting integers are used. For [[ and $ partial matching is used if exact matching fails, so x$aa will match x$aabb if x does not contain a component named "aa" and "aabb" is the only name which has prefix "aa". For [[, partial matching can be controlled via the exact argument which defaults to NA indicating that partial matching is allowed, but should result in a warning when it occurs. Setting exact to TRUE prevents partial matching from occurring, a FALSE value allows it and does not issue any warnings. Note that [ always requires an exact match. The string "" is treated specially: it indicates ‘no name’ and matches no element (not even those without a name). Note that partial matching is only used when extracting and not when replacing.
• Factor. The result is identical to x[as.integer(i)]. The factor levels are never used. If so desired, use x[as.character(i)] or a similar construction.
• Empty. The expression x[] returns x, but drops “irrelevant” attributes from the result. Only names and in multi-dimensional arrays dim and dimnames attributes are retained.
• NULL. This is treated as if it were integer(0).

Indexing with a missing (i.e. NA) value gives an NA result. This rule applies also to the case of logical indexing, i.e. the elements of x that have an NA selector in i get included in the result, but their value will be NA.

3.4.2 Indexing matrices and arrays ¶

> m <- matrix(1:4, 2)
> m
     [,1] [,2]
[1,]    1    3
[2,]    2    4
> i <- matrix(c(1, 1, 2, 2), 2, byrow = TRUE)
> i
     [,1] [,2]
[1,]    1    1
[2,]    2    2
> m[i]
[1] 1 4

Both in the case of using a single index and in matrix indexing, a names attribute is used if present, as had the structure been one-dimensional.

3.4.3 Indexing other structures ¶

The operator [ is a generic function which allows class methods to be added, and the $ and [[ operators likewise. Thus, it is possible to have user-defined indexing operations for any structure. Such a function, say [.foo is called with a set of arguments of which the first is the structure being indexed and the rest are the indices. In the case of $, the index argument is of mode "symbol" even when using the x$"abc" form. It is important to be aware that class methods do not necessarily behave in the same way as the basic methods, for example with respect to partial matching.

The most important example of a class method for [ is that used for data frames. It is not described in detail here (see the help page for [.data.frame), but in broad terms, if two indices are supplied (even if one is empty) it creates matrix-like indexing for a structure that is basically a list of vectors of the same length. If a single index is supplied, it is interpreted as indexing the list of columns—in that case the drop argument is ignored, with a warning.

The basic operators $ and [[ can be applied to environments. Only character indices are allowed and no partial matching is done.

3.4.4 Subset assignment ¶

x[3:5] <- 13:15

`*tmp*` <- x
x <- "[<-"(`*tmp*`, 3:5, value=13:15)
rm(`*tmp*`)

names(x) <- c("a","b")

`*tmp*` <- x
x <- "names<-"(`*tmp*`, value=c("a","b"))
rm(`*tmp*`)

names(x)[3] <- "Three"

`*tmp*` <- x
x <- "names<-"(`*tmp*`, value="[<-"(names(`*tmp*`), 3, value="Three"))
rm(`*tmp*`)

names(x)[3] <<- "Three"

`*tmp*` <<- get(x, envir=parent.env(), inherits=TRUE)
names(`*tmp*`)[3] <- "Three"
x <<- `*tmp*`
rm(`*tmp*`)

`*tmp*` <- get(x,envir=parent.env(), inherits=TRUE)
x <<- "names<-"(`*tmp*`, value="[<-"(names(`*tmp*`), 3, value="Three"))
rm(`*tmp*`)

e<-c(a=1,b=2)
i<-1
local({
   e <- c(A=10,B=11)
   i <-2
   e[i] <<- e[i]+1
})

 a  b 
 1 12

`*tmp*` <- get(e, envir=parent.env(), inherits=TRUE)
`*tmp*`[i] <- e[i]+1
e <<- `*tmp*`
rm(`*tmp*`)

x[is.na(x)] <<- 0

`*tmp*` <- get(x,envir=parent.env(), inherits=TRUE)
`*tmp*`[is.na(x)] <- 0
x <<- `*tmp*`
rm(`*tmp*`)

`*tmp*` <- get(x,envir=parent.env(), inherits=TRUE)
`*tmp*`[is.na(`*tmp*`)] <- 0
x <<- `*tmp*`
rm(`*tmp*`)

3.5.1 Global environment ¶

The global environment is the root of the user workspace. An assignment operation from the command line will cause the relevant object to belong to the global environment. Its enclosing environment is the next environment on the search path, and so on back to the empty environment that is the enclosure of the base environment.

3.5.2 Lexical environment ¶

Every call to a function creates a frame which contains the local variables created in the function, and is evaluated in an environment, which in combination creates a new environment.

A closure (mode "function") object will contain the environment in which it is created as part of its definition (By default. The environment can be manipulated using environment<-). When the function is subsequently called, its evaluation environment is created with the closure’s environment as enclosure. Notice that this is not necessarily the environment of the caller!

Thus, when a variable is requested inside a function, it is first sought in the evaluation environment, then in the enclosure, the enclosure of the enclosure, etc.; once the global environment or the environment of a package is reached, the search continues up the search path to the environment of the base package. If the variable is not found there, the search will proceed next to the empty environment, and will fail.

3.5.3 The call stack ¶

Every time a function is invoked a new evaluation frame is created. At any point in time during the computation the currently active environments are accessible through the call stack. Each time a function is invoked a special construct called a context is created internally and is placed on a list of contexts. When a function has finished evaluating its context is removed from the call stack.

Making variables defined higher up the call stack available is called dynamic scope. The binding for a variable is then determined by the most recent (in time) definition of the variable. This contradicts the default scoping rules in R, which use the bindings in the environment in which the function was defined (lexical scope). Some functions, particularly those that use and manipulate model formulas, need to simulate dynamic scope by directly accessing the call stack.

Access to the call stack is provided through a family of functions which have names that start with ‘sys.’. They are listed briefly below.

3.5.4 Search path ¶

In addition to the evaluation environment structure, R has a search path of environments which are searched for variables not found elsewhere. This is used for two things: packages of functions and attached user data.

4.1.1 Syntax and examples ¶

The syntax for writing a function is

function ( arglist ) body

An argument list is a comma separated list of formal arguments. A formal argument can be a symbol, a statement of the form ‘symbol = expression’, or the special formal argument ....

Generally functions are assigned to symbols but they don’t need to be. The value returned by the call to function is a function. If this is not given a name it is referred to as an anonymous function. Anonymous functions are most frequently used as arguments to other functions such as the apply family or outer.

4.1.2 Arguments ¶

The formal arguments to the function define the variables whose values will be supplied at the time the function is invoked. The names of these arguments can be used within the function body where they obtain the value supplied at the time of function invocation.

Default values for arguments can be specified using the special form ‘name = expression’. In this case, if the user does not specify a value for the argument when the function is invoked the expression will be associated with the corresponding symbol. When a value is needed the expression is evaluated in the evaluation frame of the function.

Default behaviours can also be specified by using the function missing. When missing is called with the name of a formal argument it returns TRUE if the formal argument was not matched with any actual argument and has not been subsequently modified in the body of the function. An argument that is missing will thus have its default value, if any. The missing function does not force evaluation of the argument.

The special type of argument ... can contain any number of supplied arguments. It is used for a variety of purposes. It allows you to write a function that takes an arbitrary number of arguments. It can be used to absorb some arguments into an intermediate function which can then be extracted by functions called subsequently.

4.3.1 Evaluation environment ¶

When a function is called or invoked a new evaluation frame is created. In this frame the formal arguments are matched with the supplied arguments according to the rules given in Argument matching. The statements in the body of the function are evaluated sequentially in this environment frame.

4.3.2 Argument matching ¶

This subsection applies to closures but not to primitive functions. The latter typically ignore tags and do positional matching, but their help pages should be consulted for exceptions, which include log, round, signif, rep and seq.int.

The first thing that occurs in a function evaluation is the matching of formal to the actual or supplied arguments. This is done by a three-pass process:

1. Exact matching on tags. For each named supplied argument the list of formal arguments is searched for an item whose name matches exactly. It is an error to have the same formal argument match several actuals or vice versa.
2. Partial matching on tags. Each remaining named supplied argument is compared to the remaining formal arguments using partial matching. If the name of the supplied argument matches exactly with the first part of a formal argument then the two arguments are considered to be matched. It is an error to have multiple partial matches. Notice that if f <- function(fumble, fooey) fbody, then f(f = 1, fo = 2) is illegal, even though the 2nd actual argument only matches fooey. f(f = 1, fooey = 2) is legal though since the second argument matches exactly and is removed from consideration for partial matching. If the formal arguments contain ... then partial matching is only applied to arguments that precede it.
3. Positional matching. Any unmatched formal arguments are bound to unnamed supplied arguments, in order. If there is a ... argument, it will take up the remaining arguments, tagged or not.

Argument matching is augmented by the functions match.arg, match.call and match.fun. Access to the partial matching algorithm used by R is via pmatch.

4.3.3 Argument evaluation ¶

One of the most important things to know about the evaluation of arguments to a function is that supplied arguments and default arguments are treated differently. The supplied arguments to a function are evaluated in the evaluation frame of the calling function. The default arguments to a function are evaluated in the evaluation frame of the function.

The semantics of invoking a function in R argument are call-by-value. In general, supplied arguments behave as if they are local variables initialized with the value supplied and the name of the corresponding formal argument. Changing the value of a supplied argument within a function will not affect the value of the variable in the calling frame.

R has a form of lazy evaluation of function arguments. Arguments are not evaluated until needed. It is important to realize that in some cases the argument will never be evaluated. Thus, it is bad style to use arguments to functions to cause side-effects. While in C it is common to use the form, foo(x = y) to invoke foo with the value of y and simultaneously to assign the value of y to x this same style should not be used in R. There is no guarantee that the argument will ever be evaluated and hence the assignment may not take place.

It is also worth noting that the effect of foo(x <- y) if the argument is evaluated is to change the value of x in the calling environment and not in the evaluation environment of foo.

It is possible to access the actual (not default) expressions used as arguments inside the function. The mechanism is implemented via promises. When a function is being evaluated the actual expression used as an argument is stored in the promise together with a pointer to the environment the function was called from. When (if) the argument is evaluated the stored expression is evaluated in the environment that the function was called from. Since only a pointer to the environment is used any changes made to that environment will be in effect during this evaluation. The resulting value is then also stored in a separate spot in the promise. Subsequent evaluations retrieve this stored value (a second evaluation is not carried out). Access to the unevaluated expression is also available using substitute.

When a function is called, each formal argument is assigned a promise in the local environment of the call with the expression slot containing the actual argument (if it exists) and the environment slot containing the environment of the caller. If no actual argument for a formal argument is given in the call and there is a default expression, it is similarly assigned to the expression slot of the formal argument, but with the environment set to the local environment.

The process of filling the value slot of a promise by evaluating the contents of the expression slot in the promise’s environment is called forcing the promise. A promise will only be forced once, the value slot content being used directly later on.

A promise is forced when its value is needed. This usually happens inside internal functions, but a promise can also be forced by direct evaluation of the promise itself. This is occasionally useful when a default expression depends on the value of another formal argument or other variable in the local environment. This is seen in the following example where the lone label ensures that the label is based on the value of x before it is changed in the next line.

function(x, label = deparse(x)) {
    label
    x <- x + 1
    print(label)
}

4.3.4 Scope ¶

Scope or the scoping rules are simply the set of rules used by the evaluator to find a value for a symbol. Every computer language has a set of such rules. In R the rules are fairly simple but there do exist mechanisms for subverting the usual, or default rules.

R adheres to a set of rules that are called lexical scope. This means the variable bindings in effect at the time the expression was created are used to provide values for any unbound symbols in the expression.

Most of the interesting properties of scope are involved with evaluating functions and we concentrate on this issue. A symbol can be either bound or unbound. All of the formal arguments to a function provide bound symbols in the body of the function. Any other symbols in the body of the function are either local variables or unbound variables. A local variable is one that is defined within the function. Because R has no formal definition of variables, they are simply used as needed, it can be difficult to determine whether a variable is local or not. Local variables must first be defined, this is typically done by having them on the left-hand side of an assignment.

During the evaluation process if an unbound symbol is detected then R attempts to find a value for it. The scoping rules determine how this process proceeds. In R the environment of the function is searched first, then its enclosure and so on until the global environment is reached.

When this set of rules is combined with the fact that functions can be returned as values from other functions then some rather nice, but at first glance peculiar, properties obtain.

f <- function() {
    y <- 10
    g <- function(x) x + y
    return(g)
}
h <- f()
h(3)

When h(3) is evaluated we see that its body is that of g. Within that body x is bound to the formal argument and y is unbound. In a language with lexical scope x will be associated with the value 3 and y with the value 10 local to f so h(3) should return the value 13. In R this is indeed what happens.

10.1.1 Modes of parsing ¶

Parsing in R occurs in three different variants:

• The read-eval-print loop
• Parsing of text files
• Parsing of character strings

The read-eval-print loop forms the basic command line interface to R. Textual input is read until a complete R expression is available. Expressions may be split over several input lines. The primary prompt (by default ‘> ’) indicates that the parser is ready for a new expression, and a continuation prompt (by default ‘+ ’) indicates that the parser expects the remainder of an incomplete expression. The expression is converted to internal form during input and the parsed expression is passed to the evaluator and the result is printed (unless specifically made invisible). If the parser finds itself in a state which is incompatible with the language syntax, a “Syntax Error” is flagged and the parser resets itself and resumes input at the beginning of the next input line.

Text files can be parsed using the parse function. In particular, this is done during execution of the source function, which allows commands to be stored in an external file and executed as if they had been typed at the keyboard. Note, though, that the entire file is parsed and syntax checked before any evaluation takes place.

Character strings, or vectors thereof, can be parsed using the text= argument to parse. The strings are treated exactly as if they were the lines of an input file.

10.1.2 Internal representation ¶

Parsed expressions are stored in an R object containing the parse tree. A fuller description of such objects can be found in Language objects and Expression objects. Briefly, every elementary R expression is stored in function call form, as a list with the first element containing the function name and the remainder containing the arguments, which may in turn be further R expressions. The list elements can be named, corresponding to tagged matching of formal and actual arguments. Note that all R syntax elements are treated in this way, e.g. the assignment x <- 1 is encoded as "<-"(x, 1).

10.1.3 Deparsing ¶

Any R object can be converted to an R expression using deparse. This is frequently used in connection with output of results, e.g. for labeling plots. Notice that only objects of mode "expression" can be expected to be unchanged by reparsing the output of deparsing. For instance, the numeric vector 1:5 will deparse as "c(1, 2, 3, 4, 5)", which will reparse as a call to the function c. As far as possible, evaluating the deparsed and reparsed expression gives the same result as evaluating the original, but there are a couple of awkward exceptions, mostly involving expressions that weren’t generated from a textual representation in the first place.

10.3.1 Constants ¶

There are five types of constants: integer, logical, numeric, complex and string.

In addition, there is the special constant NULL. Also, the numeric Inf, and NaN, the logical NA, and NA_character_, NA_integer_, NA_real_, and NA_complex_ deserve mentioning; for the latter, see NA handling.

NULL is used to indicate the empty object. NA is used for absent (“Not Available”) data values. Inf denotes infinity and NaN is not-a-number in the IEEE floating point calculus (results of the operations respectively 1/0 and 0/0, for instance).

Logical constants are either TRUE, FALSE or NA.

Numeric constants follow a similar syntax to that of the C language. They consist of an integer part consisting of zero or more digits, followed optionally by ‘.’ and a fractional part of zero or more digits optionally followed by an exponent part consisting of an ‘E’ or an ‘e’, an optional sign and a string of one or more digits. Either the fractional or the decimal part can be empty, but not both at once.

Valid numeric constants: 1 10 0.1 .2 1e-7 1.2e+7

Numeric constants can also be hexadecimal, starting with ‘0x’ or ‘0x’ followed by zero or more digits, ‘a-f’ or ‘A-F’. Hexadecimal floating point constants are supported using C99 syntax, e.g. ‘0x1.1p1’.

There is now a separate class of integer constants. They are created by using the qualifier L at the end of the number. For example, 123L gives an integer value rather than a numeric value. The suffix L can be used to qualify any non-complex number with the intent of creating an integer. So it can be used with numbers given by hexadecimal or scientific notation. However, if the value is not a valid integer, a warning is emitted and the numeric value created. The following shows examples of valid integer constants, values which will generate a warning and give numeric constants and syntax errors.

Valid integer constants:  1L, 0x10L, 1000000L, 1e6L
Valid numeric constants:  1.1L, 1e-3L, 0x1.1p-2
Syntax error:  12iL 0x1.1

A warning is emitted for decimal values that contain an unnecessary decimal point, e.g. 1.L. It is an error to have a decimal point in a hexadecimal constant without the binary exponent.

Note also that a preceding sign (+ or -) is treated as a unary operator, not as part of the constant.

Up-to-date information on the currently accepted formats can be found by ?NumericConstants.

Complex constants have the form of a decimal numeric constant followed by ‘i’. Notice that only purely imaginary numbers are actual constants, other complex numbers are parsed a unary or binary operations on numeric and imaginary numbers.

Valid complex constants: 2i 4.1i 1e-2i

String constants are delimited by a pair of single (‘'’) or double (‘"’) quotes and can contain all other printable characters. Quotes and other special characters within strings are specified using escape sequences:

\'

single quote

\"

double quote

\n

newline (aka ‘line feed’, LF)

\r

carriage return (CR)

\t

tab character

\b

backspace

\a

bell

\f

form feed

\v

vertical tab

\\

backslash itself

\nnn

character with given octal code – sequences of one, two or three digits in the range 0 ... 7 are accepted.

\xnn

character with given hex code – sequences of one or two hex digits (with entries 0 ... 9 A ... F a ... f).

\unnnn \u{nnnn}

(where multibyte locales are supported, otherwise an error). Unicode character with given hex code – sequences of up to four hex digits. The character needs to be valid in the current locale.

\Unnnnnnnn \U{nnnnnnnn}

(where multibyte locales are supported, otherwise an error). Unicode character with given hex code – sequences of up to eight hex digits.

A single quote may also be embedded directly in a double-quote delimited string and vice versa.

A NUL (\0) is not allowed in a character string, so using \0 in a string constant terminates the constant (usually with a warning): further characters up to the closing quote are scanned but ignored.

10.3.2 Identifiers ¶

Notice also that objects can have names that are not identifiers. These are generally accessed via get and assign, although they can also be represented by text strings in some limited circumstances when there is no ambiguity (e.g. "x" <- 1). As get and assign are not restricted to names that are identifiers they do not recognise subscripting operators or replacement functions. The following pairs are not equivalent

10.3.3 Reserved words ¶

The following identifiers have a special meaning and cannot be used for object names

if else repeat while function for in next break
TRUE FALSE NULL Inf NaN
NA NA_integer_ NA_real_ NA_complex_ NA_character_
... ..1 ..2 etc.

10.3.4 Special operators ¶

R allows user-defined infix operators. These have the form of a string of characters delimited by the ‘%’ character. The string can contain any printable character except ‘%’. The escape sequences for strings do not apply here.

Note that the following operators are predefined:

%% %*% %/% %in% %o% %x% %||%

10.3.5 Separators ¶

Although not strictly tokens, stretches of whitespace characters (spaces, tabs and form feeds, on Windows and UTF-8 locales other Unicode whitespace characters⁵) serve to delimit tokens in case of ambiguity, (compare x<-5 and x < -5).

Newlines have a function which is a combination of token separator and expression terminator. If an expression can terminate at the end of the line the parser will assume it does so, otherwise the newline is treated as whitespace. Semicolons (‘;’) may be used to separate elementary expressions on the same line.

10.3.6 Operator tokens ¶

R uses the following operator tokens

(Several of the operators have different meaning inside model formulas)

10.3.7 Grouping ¶

Ordinary parentheses—‘(’ and ‘)’—are used for explicit grouping within expressions and to delimit the argument lists for function definitions and function calls.

Braces—‘{’ and ‘}’—delimit blocks of expressions in function definitions, conditional expressions, and iterative constructs.

10.3.8 Indexing tokens ¶

Indexing of arrays and vectors is performed using the single and double brackets, ‘[]’ and ‘[[]]’. Also, indexing tagged lists may be done using the ‘$’ operator.

10.4.1 Function calls ¶

function_reference ( arg1, arg2, ...... , argn )

f(x)
g(tag = value, , 5)
"odd name"("strange tag" = 5, y)
(function(x) x^2)(5)

10.4.2 Infix and prefix operators ¶

The order of precedence (highest first) of the operators is

::
$ @
^
- +                (unary)
:
%xyz% |>
* /
+ -                (binary)
> >= < <= == !=
!
& &&
| ||
~                  (unary and binary)
-> ->>
<- <<-
=                  (as assignment)

Note that : precedes binary +/-, but not ^. Hence, 1:3-1 is 0 1 2, but 1:2^3 is 1:8.

The exponentiation operator ‘^’ and the left assignment plus minus operators ‘<- - = <<-’ group right to left, all other operators group left to right. That is, 2 ^ 2 ^ 3 is 2 ^ 8, not 4 ^ 3, whereas 1 - 1 - 1 is -1, not 1.

The ‘$’ sign is in some sense an operator, but does not allow arbitrary right hand sides and is discussed under Index constructions. It has higher precedence than any of the other operators.

The parsed form of a unary or binary operation is completely equivalent to a function call with the operator as the function name and the operands as the function arguments.

Parentheses are recorded as equivalent to a unary operator, with name "(", even in cases where the parentheses could be inferred from operator precedence (e.g., a * (b + c)).

Notice that the assignment symbols are operators just like the arithmetic, relational, and logical ones. Any expression is allowed also on the target side of an assignment, as far as the parser is concerned (2 + 2 <- 5 is a valid expression as far as the parser is concerned. The evaluator will object, though). Similar comments apply to the model formula operator.

10.4.3 Index constructions ¶

R has three indexing constructs, two of which are syntactically similar although with somewhat different semantics:

object [ arg1, ...... , argn ]
object [[ arg1, ...... , argn ]]

object $ tag

10.4.4 Compound expressions ¶

A compound expression is of the form

{ expr1 ; expr2 ; ...... ; exprn }

The semicolons may be replaced by newlines. Internally, this is stored as a function call with "{" as the function name and the expressions as arguments.

10.4.5 Flow control elements ¶

R contains the following control structures as special syntactic constructs

if ( cond ) expr
if ( cond ) expr1 else expr2
while ( cond ) expr
repeat expr
for ( var in list ) expr

The expressions in these constructs will typically be compound expressions.

Within the loop constructs (while, repeat, for), one may use break (to terminate the loop) and next (to skip to the next iteration).

Internally, the constructs are stored as function calls:

"if"(cond, expr)
"if"(cond, expr1, expr2)
"while"(cond, expr)
"repeat"(expr)
"for"(var, list, expr)
"break"()
"next"()

10.4.6 Function definitions ¶

A function definition is of the form

function ( arglist ) body