R Functions Exercises: 18 Default Arg, Closure and Dots Problems

Explanation: A function is created with function(args) body and the last expression in the body is its return value, so an explicit return() is unnecessary for the common case. The ^ operator has higher precedence than /, so weight_kg / height_m^2 parses as the intended weight_kg / (height_m^2). Functions are first-class objects in R: you can pass them as arguments, store them in lists, and return them from other functions.

Explanation: Default arguments are evaluated lazily inside the function body, which means a default can depend on other arguments of the same call, for example function(x, y = x * 2). Defaults make a function callable with the most common path on autopilot while keeping advanced overrides available. If you want the default to be required, write offset = stop("supply offset") and the error fires only when the argument is actually used.

Explanation: match.arg() is the idiomatic way to validate a string option against an allowed set. When the default is the full allowed vector and match.arg() is called with no arguments, the first element becomes the default value. It also supports partial matching, so forecast_label("rai") would resolve to "rain". Pass an unknown value and you get Error in match.arg: 'arg' should be one of "sunny", "cloudy", "rain", "snow", which is more helpful than a custom stop().

Explanation: missing() is TRUE only when the caller did not supply the argument and the argument has no default value. It is more accurate than checking is.null(pct) because NULL may be a legitimate value the caller wanted to pass. The common alternative is to set pct = NULL as a default and check is.null(pct), which is fine when NULL is not a meaningful input. Reach for missing() when you need to distinguish "not passed" from "passed as NULL".

Explanation: Inside a function, ... is a special symbol that collects every unmatched extra argument the caller passed. You consume it with c(...) to flatten or list(...) to keep elements separate. The dots argument is positional and lazy, meaning each piece is only evaluated when you actually touch it. Picking out a single dot by name uses ..1, ..2 and so on, while ...length() reports how many extra arguments were passed.

Explanation: list(...) keeps each input vector as a separate list element, which is what you need for an element-wise reduction. Reduce("+", vecs) applies + left-to-right across the list, leveraging R's vectorised arithmetic: 1:3 + 10:12 = c(11, 13, 15), and so on. Compared to do.call("+", vecs), Reduce scales to any number of inputs whereas the binary + only takes two operands directly. For a length-mismatch input set, this approach silently recycles, so a leading stopifnot(length(unique(lengths(vecs))) == 1) is a useful guardrail in production.

Explanation: Forwarding ... directly to another function is the most common dots pattern in the tidyverse and base R: every named argument the user passes flows through unchanged. The trick is that safe_mean already hard-codes na.rm = TRUE, so the caller cannot reset it; if they pass na.rm = FALSE it would either be silently shadowed or raise a duplicate-argument error depending on argument matching. To keep both behaviours, drop the hard-coded value and rely entirely on ..., or use if (!"na.rm" %in% names(list(...))) to inject the default only when absent.

Explanation: R arguments are not evaluated when the function is called, only when the body actually references them. This is called lazy evaluation and it is implemented via promises: each argument is bundled with its expression and the enclosing environment, then forced on first use. The pattern shows up in real code as defaults like function(x, n = length(x)) where n depends on x. It also has a footgun: if a default has a side effect, you have no guarantee it ever fires, so never put log writes or counters in default expressions.

Explanation: A closure is a function plus the environment in which it was defined. When make_counter returns the inner function, that environment, containing count, survives as long as the returned closure is reachable. The <<- operator walks up parent environments to find count and assigns to it in place, which is what gives the counter its memory. Each call to make_counter() builds a fresh enclosing environment, so two counters never share state. This is the core mechanism behind R6 classes, memoisation, and most stateful gadgets in R.

Explanation: Memoisation trades memory for speed by caching results, and closures are the natural home for the cache because the environment is private and persists across calls. Using a list keyed by as.character(x) is the simplest implementation; for multi-argument functions and richer keys, the memoise package on CRAN uses digest::digest() to hash the inputs. The trade-off is that the cache grows without bound unless you cap it (an LRU eviction is a typical fix), and the cache key collapses numerically distinct values that share a string representation.

Explanation: on.exit() registers an expression to be run when the enclosing function exits, no matter whether it returned normally or threw an error. This is the R idiom for "finally" blocks and is essential for closing database connections, restoring options(), releasing file handles, or removing scratch files. Place on.exit() immediately after creating the resource so a later error cannot bypass cleanup. By default a second on.exit() overwrites the first; use on.exit(expr, add = TRUE) to stack handlers.

Explanation: Since R 4.1, \(x) expr is a backslash shorthand for function(x) expr, much like Haskell's \x -> expr or Python's lambda x:. It is exactly equivalent to writing function(x) mean(x) and saves four characters per call site, which adds up when threading anonymous functions through sapply, Map, Reduce, or pipe sequences. A data frame is internally a list of columns, so sapply() walks each column. Of course sapply(mtcars, mean) works too, since mean is already a function and no lambda is required.

Explanation: Filter(predicate, x) keeps elements of x for which the predicate is TRUE. Because data frames are lists of columns, Filter(is.numeric, iris) walks each column and keeps the numeric ones. A predicate is any function that returns a logical scalar: is.character, is.factor, \(c) length(unique(c)) > 1. The base sibling Find() returns the first matching element, and Position() returns its index. These are the same building blocks that show up across functional languages, just spelled with title case in base R.

Explanation: Reduce(f, x, init) walks x left to right, threading an accumulator through f(acc, elem) calls and returning the final accumulator. Setting init = x and passing a list of functions turns the reduction into function composition: start with the input value, apply each function in turn. The trace here is 15 to 16 (plus 1), 16 to 4 (square root), 4 to 4 (round). The same idea generalises to fold operations in any functional language. For right-to-left composition, pass right = TRUE.

Explanation: Currying converts an n-argument function into a chain of n one-argument functions, named after Haskell Curry. Each nested closure captures the argument it received and waits for the next one. In R this is rarely written by hand because partial application via purrr::partial() or a simple \(x) f(a, b, x) is usually clearer, but the exercise pins down what closures actually carry: the chain works because each returned function remembers the values of a and b in its parent environments long after those parent calls have returned.

Explanation: R functions return exactly one object, so when you need to surface multiple values the conventional answer is a named list, which then unpacks at the call site with result$mean. A named numeric vector via c(mean = mean(x), ...) is shorter when all values are scalars of the same type, but loses generality once you want to mix types (a vector and a data frame, say). For richer return types, an S3 class like structure(list(...), class = "describe_result") gives you a hook for a custom print method.

Explanation: Recursion in R works just like in any other language: a function calls itself with a smaller input until a base case returns directly. The base case here is n <= 1, returning 1 for both 0! and 1!. R does not optimise tail calls, so deep recursions blow the call stack at depth options("expressions"), currently 5000. For factorial specifically the iterative prod(seq_len(n)) is faster, simpler, and immune to that limit; recursion shines when the structure of the problem is itself recursive, such as walking a tree.

Explanation: The naive recursive Fibonacci is exponential, computing fib(25) calls the function more than 200 thousand times. Caching prior results in the enclosing environment with <<- makes the recurrence linear in n because each fib(k) returns from cache after the first call. The closure pattern works because the inner fib is named, captured by the surrounding environment, and is what <<- writes into. An alternative is the memoise package on CRAN, which gives you the same speedup with one wrapper call and richer caches.