7 Environments

7.1 Environment basics

  1. Q: List three ways in which an environment differs from a list.

    A: The most important differences between environments and lists are:
    • environments have reference semantics
    • environments have parents
    • environments are not ordered
    • elements of environments need to be (uniquely) named
  2. Q: Create an environment as illustrated by this picture.

    A: Let’s create an environment, that contains itsself.

  3. Q: Create a pair of environments as illustrated by this picture.

    A: These two environments contain each other:

  4. Q: Explain why e[[1]] and e[c("a", "b")] don’t make sense when e is an environment.

    A: The first option doesn’t make sense, because elements of an environment are not ordered. The second option would return two objects at the same time without being contained in another data structure. Therefore, it would be unclear how R should handle this type of output.

  5. Q: Create a version of env_poke() that will only bind new names, never re-bind old names. Some programming languages only do this, and are known as single assignment languages.

    A: We want env_poke2() to test, if the supplied name is already present in the given environment. We only allow new names to be assigned to a value, otherwise an (informative) error is thrown.

  6. Q: What does this function do? How does it differ from <<- and why might you prefer it?

    A: The function does “more or less” the same as <<-. rebind() provides an additional env argument (but this functionality is already coverd by assign()). More importantly, rebind() will only carry out an assignment when it finds a binding in one of the parent environments of env. This is different than the behaviour of <<- (see textbook):

    If <<- doesn’t find an existing variable, it will create one in the global environment. This is usually undesirable, because global variables introduce non-obvious dependencies between functions.

7.2 Recursing over environments

  1. Q: Modify where() to return all environments that contain a binding for name. Carefully think through what type of object the function will need to return.

    A: The modified function will always recurse until it reaches the empty environment. Along the way, it will check each environment for a given name. Only if no matching object is found in any environment, an error will be thrown. Otherwise the environments containing matching objects will be written to a list, which will be returned once the function terminates. Please also note how the list is initialized via the default argument, when the function is called for the first time.

  2. Q: Write a function called fget() that finds only function objects. It should have two arguments, name and env, and should obey the regular scoping rules for functions: if there’s an object with a matching name that’s not a function, look in the parent. For an added challenge, also add an inherits argument which controls whether the function recurses up the parents or only looks in one environment.

    A: We follow a similar approach to the previous exercise. This time we additionally check if the found object is a function and implement and argument to turn off the recursion, if desired.

7.3 Special environments

  1. Q: How is search_envs() different fo env_parents(global_env())?

    A: search_envs() returns all the environments on the search path. “The search path is a chain of environments containing exported functions of attached packages” (from ?search_envs). Every time you attach a new package, this search path will grow. The search path ends with the base-environment. The global environment is included, because functions present in the global environment will always be part of the search path.

    env_parents(global_env()) will list all the ancestors of the global environment, therefore the global environment itsself is not included. This also includes the “ultimate ancestor”, the empty environment. This environment is not part of the search path, because it contains no objects would need to be found.

  2. Q: Draw a diagram that shows the enclosing environments of this function:

    A: Each function environment binds its parent environment. The function environments contain functions and the values provided in the function call.

  3. Q: Write an enhanced version of str() that provides more information about functions. Show where the function was found and what environment it was defined in.

    A: Apart from the requested features, let us also provide the function type (see ?pryr::ftype for details). We use functions from the pryr package, since it provides helpers for all requested features:

    We chose to use non-standard evaluation for the input just like str() does. pryr::where() requires character input. We catch the name of the supplied object and use lazyeval::expr_text() (https://github.com/hadley/lazyeval) to create the string we need.

7.4 The call stack

  1. Q: Write a function that lists all the variables defined in the environment in which it was called. It should return the same results as ls(). A: We can implement this dynamic scoping behaviour, by explicitly referencing the caller environment. Pleaso note, that this approach returns also variables starting with a dot - an option we also pass to ls().