O Beautiful Code

RserveCLI2, a .net client for Rserve

2013-03-21T00:00:00-04:00

RserveCLI is a .net/cli client for Rserve, created by Oliver M. Haynold. Oliver has done a great job with this project.

I forked this project to add features, fix bugs, and do some restructuring. I thought it was a significant enough depature to create a new project.

To that end, I’m hosting RserveCLI2 on github.

Contributions appreciated!

Nixed Amazon Linux

2013-02-28T00:00:00-05:00

I’m using EC2, I just can’t use Amazon Linux. Let me explain…

Solve for Dev/Prod Parity

My company is committed to the principal of dev/prod parity to minimize deployment failures. That means our development environment is as close as possible to our production environment. Unfortunately, Amazon Linux is not super accessible. It’s not published such that it can be installed on desktops, laptops, or local virtualization environments like VirtualBox. It seems there are ways to hack it, but it isn’t an out-of-the-box sort of thing.

So, there are two options for selecting an OS to run in the cloud:

Use Amazon Linux. Develop, test and deploy in EC2 (always-on instance).
Use a more accessible distro (e.g. Ubuntu which has local and cloud images). Develop and test locally and deploy in EC2.

#1 is costly where micro or small instances can’t do the job. Also, I’m uncomfortable being perpetually on-the-clock (until the day cloud computing becomes a dirt-cheap commodity).

So that leaves #2!

Not a Great Pitch

Amazon advertises some key features of Amazon Linux. I see little value-add:

AWS Integration - It’s plenty easy to install the AWS API tools on other distros. Also, CloudInit supports a particular configuration management strategy, which is not the one we use. Also, CloudInit fails dev/prod parity =)
Secure Configuration - The advertised security features (i.e. disable root, enable SSH key pairs) are basic. Those should be implemented always. I can reduce non-critical packages to limit the threat surface just as well as Amazon can. Also, it’s straight-forward to automatically apply security updates.
Package repository access - ok, Amazon Linux wins. It will be blazing fast to hit their package repo. I don’t understand their point about data transfer charges. The last I checked there is no fee for data transferred into EC2 from the internet. So it should be mostly free to pull packages from non-Amazon repositories.
Lightweight - Here they just repeat their point about security and non-critical packages.
Available in All Regions, Formats, and Architectures - It seems the Ubuntu cloud images are just as broadly available.
AWS Support - Clearly they will be better at supporting their OS on their own platform. The value is a bit hard to quantify, though. And of course you have to pay extra for support.

Ideally…

The theoretically best solution to dev/prod parity is to use a cloud that you can install locally such as OpenStack. I think this platform lacks the maturity of AWS.

Simple Software, a Tutorial

2013-02-25T00:00:00-05:00

I’m a compulsive note-taker (using OneNote, which I think tops all other products in the category). I like to condense information, in plain english, and codify insights so I can refer to them later when I need a refresher.

Here’s my notes from Rich Hickey’s 2011 talk “Simple Made Easy” (augmented with bits from his 2012 RailsConf talk). This is extraordinary! It’s near the top of my list of software engineering resources (across all formats - talks, books, etc.). If you haven’t seen the talk, go watch it and I promise you will be so much wiser for it.

It was a small bit of effort to find the deck, so I’m hosting it for your convenience. My notes are a synthesis of the talk, the deck, and some of my own material where I felt it aided in understanding.

The Simple

A simple piece of software means that there is no interleaving. It doesn’t combine things. It has focus. Something is simple when it addresses: one role, one task, one concept, one dimension
Simple doesn’t mean there is only one of them. Its not about an interface with one operation or a class with one instance. It’s not about cardinality.
By contrast, a complex system is braided or folded together. There are interleaving roles, tasks, concepts, or dimensions.
Identifying a system as simple or complex is thus objective. If there are twists, its complex. If there is no interleaving, it’s simple.

The Easy

Simple is often (disadvantageously) confused with easy. Easy means near:
- near at hand - ability to start using it locally. Hickey says, “We are infatuated with this aspect of easy. Can I get this instantly and start installing it in 5 seconds. It could be this giant hairball…”
- my take: It’s almost a requirement these days that a new framework or library boasts a 4-lines-of-code quick-start. The implicit message is “this is so easy, it must be good.” A year later you wonder if you should have explored it some more before taking the dependency and now you’re tangled in the technology.
- near to our understand or skillset. It’s familiar. It’s like something we already know, plus one new thing. Hickey says, “If you want everything to be familiar you will never learn anything new because it cannot be significantly different from what you already know and not drift away from the familiarity.”
- near to our capabilities, within our mental capacity, not overly taxing on our brain. Hickey says, “this starts trampling on our egos…due to combination of hubris and insecurity we never talk about something being outside of our capabilities”
Easy is relative to a specific person. Easy for whom? Simple is objective.
We are too focused on the experience of programming rather than the artifacts - the programs that gets produced and run. We should assess quality based on our artifacts, not on the experience of typing programs into an editor!

Reasoning

Humans have limitations:
- If we can’t understand our software, we can’t make it reliable. As we make things more flexible and dynamic, we tradeoff ability to understand their nature and ensure they work properly.
- my take: We’ve all been there - you’re traversing a hierarchy of abstract classes and interfaces and the control was certainly inverted and the dependencies were injected and various design patterns were used and you were just trying to figure out how this one thing works and you’re asking yourself “why is this so complicated?”
- If two things are intertwined, you have the burden of taking both of them into your mind when you are working on one.
- my take: Again, we’ve all been there - system A depends on system B being in a certain state, which in turn depends on certain features in system C which behave differently based on the configuration file in system A and luck would have it you’ve long forgotten how system C works.
- Humans are limited in the number of things they can hold in their head.
We need to reason about our programs to change them - to add new capabilities and to fix bugs. This is not about proving programs nor category theory, just informal reasoning.
- “Apparently I heard in a talk today that Agile and Extreme programming have shown that refactoring and tests allow us to make change with zero impact. I never knew that. I still do not know that. That’s not a knowable thing. That’s fooey! If you’re going to change software you need to analyze what it does and make decisions about what it ought to do…if you can’t reason about your program you can’t make these decisions”
- Beware guardrail programming. The idea that you can make changes because you have tests. “Who drives their car around banging against the guardrail saying woah I’m glad I’ve got these guardrails because I’d never make it to the show on time…do the guardrails help you get to where you want to go?”

Agility

Developing easy systems (i.e. using Agile) is faster than developing simple systems at first. Simple systems require deliberation and thought. My take: easy systems tend start at a frantic pace. But if you ignore complexity you will slow down over the long-haul. In contrast, simple systems accelerate progress over time:
- complex constructs are often easy - they are familiar, available, etc.
- what matters is the complexity they yield. Easy constructs often yield incidental complexity.
- my take: You didn’t mean to take on the complexity, but it came for the ride and now what was easy has become a burden.
Architectural agility is the agility you get from building a system that is fundamentally simple. This kind of agility dominates all other kinds of agility. Hickey says, “Simplicity enables change…it’s the primary source of real agility. Agility means to do something. It doesn’t mean to do it over, it doesn’t mean to redo it, it doesn’t mean to undo it….It means to directly do. That’s agility. If you’re dragging an elephant around you’re never going to be agile”

Examples

Lets make this more concrete (I tried linking to resources that explain why a construct is better or worse, with a fallback to definitions):

complex	simple
state,objects	values
methods	functions, namespaces
vars	managed references
inheritance, switch statements, pattern matching	polymorphism a la carte
syntax	data
imperative loops, fold	set functions
actors	queues
ORM	declarative data manipulation
conditionals	rules
inconsistency (eventually consistent)	consistency

What makes each construct in the table above complex? The deck contains a table with two columns: the constructs and the concepts that each construct intertwines. He discusses each one briefly in the talk. I’m omitting the table. It wasn’t as helpful for me as researching each construct and reasoning about its complexity.
How do you leverage the simple constructs in the table above? Links from the first table also apply here:

construct	get it via…
values	final, persistent collections, immutables
functions	stateless methods
namespaces	language support
data	maps, arrays, sets, JSON, etc.
polymorphism a la carte	protocols, type classes
managed refs	clojure/haskell refs
set functions	libraries
queues	libraries
declarative data manipulation	SQL/LINQ/Datalog
rules	libraries, prolog
consistency	transactions, values

Designing Simple Systems

Composing simple components is the key to robust software. Composing is about placing things together, not interleaving them. Modules and layers don’t imply simplicity (but are enabled by it).
Architecture and design has become demonized. People think it means making grand plans and thus equate it with heavy, failure-prone models such as waterfall. Good design is actually about taking things apart.
Abstract means to draw something away, usually from the physical nature of something.
- It’s not about hiding stuff
- it’s is the job of designing and as such its hard to explain how to do it properly.
- One way to create abstractions is to ask: who, what, when, where, why, how? Rich explores each of these but I’m skipping this because it’s partially a repeat of the above and also presented with too broad a brushstroke.
- Another way is to say “I don’t know, I don’t want to know.”
- my take: If you’re working on System A and the topic of System B comes up, you say “I don’t know, I don’t want to know.” As soon as you want to know, you risk interleaving the two systems. System A plays a role independent of System B.
Is your system simple? You can apply a litmus test: Ask the question, “Can I move my subsystems around without changing much?” Can you move it out of process? To a different language? To a different thread?
Information is simple, don’t ruin it. Represent data as data, don’t hide it behind classes and methods. His talk on the “Value of Values” delves deep into this and is chock-full of value =)
Simplicity doesn’t fall out of tooling. You have to do the work! You need to gain sensibilities around what is simple and what is complex. Don’t lean on tools such as testing, refactoring, or type systems. They don’t care if your program is simple or not.

A Warning About warning()

2012-05-02T00:00:00-04:00

Avoid R’s warning feature. This is particularly important if you use R in production; when you regularly run R scripts as part of your business process. This is also important if you author R packages. Don’t issue warnings in your own code and treat warnings in 3rd party code as errors that are explicitly suppressed. I’ll discuss a strategy to implement this in a little bit, but first lets discuss the warning feature and the justification for this advice.

The Warning

A warning cautions users without halting the execution of a function. It basically says “although I can and will give you an answer, there might be a problem with your inputs. Thus, the computation could be flawed.” For example, the correlation function issues a warning when an input vector has a standard deviation of 0. Rather than raising an error and halting execution, the function issues a warning and returns NA.

> cor( c( 1 , 1 ), c( 2 , 3 ) )
[1] NA
Warning message:
In cor(c(1, 1), c(2, 3)) : the standard deviation is zero

To issue a warning simply call the warning() function

Division = function( x , y )
{
    if ( y == 0 ) { warning( "Divide by 0" ) }
    return( x / y )
}
> Division( 1 , 0 )
[1] Inf
Warning message:
In Division(1, 0) : Divide by 0

Multiple warnings can be issued during a function call. They can originate from the function itself or from child functions. R stores all warnings and prints them out after the function returns.

ParentFunction = function( )
{
    warning( "warning from parent" )
    ChildFunction1()
    ChildFunction2()
    warning( "second warning from parent" )
    return( TRUE )
}

ChildFunction1 = function() {  warning( "warning from child" ) }
ChildFunction2 = function() {  warning( "second warning from child" ) }

> ParentFunction()
[1] TRUE
Warning messages:
1: In ParentFunction() : warning from parent
2: In ChildFunction1() : warning from child
3: In ChildFunction2() : second warning from child
4: In ParentFunction() : second warning from parent

Avoid Warning

You should avoid warnings (as a producer and a consumer) for three reasons:

It adds unnecessary complexity.
Functions should either succeed or fail and it should be as simple as that. Warnings introduce a third state. A function author must consider when to issue a warning, how to message it, and how the function will proceed in the warning/caution state. Its difficult enough to write a good function without this burden. On the flip side, a function consumer must decide how to handle a warning. Do you continue or halt? Does it depend on the warning? If so, do you switch on specific warning messages or keywords within the message? What if the warning message changes with an updated package? It’s far less complex when a function just fails; there’s less for both parties to do.
Most warnings are actually errors.
This is anecdotal, but I’d bet it generalizes well: 80% of the time I see warnings when there’s a bug in the inputs to a function call.
You will miss critical errors.
In an automated/production environment dealing with warnings is a pain. You might miss warnings outright because no human will see it. Per #2 above, this could mean bad things. Otherwise, you will have to pipe a script’s output to a file, parse it to detect the warning and notify someone. Lets say you pull that off. You are still betting that someone will heed the warnings in a timely manner. Also, you’re left with a time-consuming and ambiguous task of deciding which warnings to addressed. If, however, your script just failed, I’m guessing you will find out pretty quick and you will have to pay attention to the issue.

Step1: Stop Warning

Instead of issuing a warning, do one of the following:

Call stop("error message here"). This will generate an error and halt execution.
Add a function parameter that specifies the action to take when the inputs are malformed. This is mostly likely a boolean (logical) parameter that indicates whether the function should fail or gives the function permission to proceed. Use a descriptive parameter. Some good prefixes are ignore and fail. For example, I’ve added parameters failSd0 and ignoreSd0 below.

Cor( x , y , failSd0 )
{
    if ( failSd0 && equals( sd( x ) , 0 ) ) { stop( "the standard deviation of x is 0" ) }
    if ( failSd0 && equals( sd( y ) , 0 ) ) { stop( "the standard deviation of y is 0" ) }
    ...
}

Cor( x , y , ignoreSd0  )
{
    if (  ( !ignoreSd0 ) && equals( sd( x ) , 0 ) ) { stop( "the standard deviation of x is 0" ) }
    if (  ( !ignoreSd0 ) && equals( sd( y ) , 0 ) ) { stop( "the standard deviation of y is 0" ) }
    ...
}

Just deciding between approach #1 and approach #2 is a useful exercise. It challenges you to judge the utility of a function in the face of specific categories of input (i.e. correlation when an input vector has standard deviation of 0). You might admit that a function’s outputs have little to no value when the inputs have a particularly quality. In that case, you would use approch #1 and just stop() the execution. This is the least complex thing to do.

Although solution #2 is a bit more work, it provides a wonderful benefit to your users. It gives them information about how not call your function. In other words, it helps them minimize failure. This information is nicely embedded into the parameter list. When a user sees the parameter failSd0 it triggers the most obvious question: “Is it possible that my x or y has a standard deviation of 0? Maybe I should check the code that populates x and y just in case.”

Step2: Strategically Maneuver 3rd Party Warnings

To consume 3rd party code (i.e. CRAN packages) that issues warnings, do the following:

Treat all warnings are errors.
Take the complexity out of the equation by first assuming that all warnings are in fact errors. Simply call options( warn = 2 ). R will convert the first warning it encounters into an error and halt execution. I recommend putting this into your Rprofile.site file so that this treatment is always applied.
Selectively suppress warnings.
There are times when a function issues a warning and you are certain that your inputs are correct and you are happy with the results. In this case, wrap the function call in suppressWarnings().

> options( warn = 2 )
> ParentFunction()
Error in ParentFunction() : (converted from warning) warning from parent
> suppressWarnings( ParentFunction() )
[1] TRUE

This is a case-by-case opt-in. Don’t wrap everything in suppressWarnings()! Be sure to add a clear justification in the comments:

# FictitiousFunction warns when myValue is 0.  myValue will always be 0.  
# This only affects result$ABC output which is fixed at NA.  We don't use this output.  
# All other elements of the result list are as expected.
suppressWarnings( FictitiousFunction( myValue ) )

Going-forward, your code could find itself in a state that triggers a 3rd party warning that you’ve never seen before. Congrats! This is a quality problem. Your code will raise an error. You can investigate the issue and in turn learn more about the package you depend on and about the behavior of your own code. And you can always suppressWarnings(). Your code will become more robust and more resilient.

Practice What You Preach

I have many thousands of lines of R code in production and I employ the strategy described above to avoid warnings. It’s a beautiful thing - I have never seen a single raw warning from R. My code simply passes or fails; there’s no third-state to deal with. Also, I sleep well knowing that my nightly processes don’t mask errors that are expressed as warnings.

Version Control - the Host Matters

2012-04-19T00:00:00-04:00

We’re moving from internally hosted SVN to Git/GitHub for the typically reasons (resounding hallelujah). Mercurial was a contender. We surveyed the available hosts and choose Git because of GitHub. Its an old adage at play here - betting on a superior toolset is just as important as betting on a technology. The benefits of Git and Mercurial largely overlap since they are distributed. Had a GitHub-like site existed for Mercurial then likely we would have sided with Mercurial for its simplicity. It’s possible to use Mercurial to push/pull from a Git repository through the Hg-Git plugin, but this scenario will always be at risk as the respective technologies evolve. Also, intentionally taking-on an additional dependency this early in the game seems awkward and unwise when it can be avoided.

The host is not the only tool in the chain, but for our purposes it’s the most impactful variable. Both Mercurial and Git have decent shell extensions with TortoiseHg and TortoiseGit. These are enhanced by replacing the diff tool with Beyond Compare. So the non-command-line-use-case is off the table. I consider the command-line tools to be a part of the core technology, but regardless hg.exe and git.exe are straight-forward for the usual tasks.

Hosts

I surveyed quite a few hosts including GitHub, Kiln, Java.net, Gitorious, SourceForge, BitBucket, RepositoryHosting, CodePlex, and Google Code. I was looking for a simple and clean UI with fluid code navigation, quick discovery and triage of code changes (code review), and ease of capturing and organizing bugs . And of course the repository needs to be private and secure. A few themes emerged:

Evaluation

It was either easy or difficult to evaluate products. The best software is usually the easiest to evaluate. The publisher wants desperately for you use their stuff. Once you try it you’ll just have to buy it because its clearly fantastic. On GitHub (and others), its hard NOT to land on a public repository in 2 clicks . Kiln was a disappointment. I had to signup for a trial, clone a public repository, and push it to my private account just to discover that I didn’t care for their Windows Explorer-like code navigation nor the admin drop-downs. Screenshots don’t cut it. Publisher will display their snazziest UI (like Kiln’s branch and merge). There’s no substitute for getting your hands dirty with software and any barriers to doing that is a red flag in my opinion.

Homepage

The repository homepage is either a dashboard of relevant/new information, the source tree, or change/commit information. The best choice is up for debate and depends on preference. I can see the argument for change/commit. A healthy codebase evolves over time and its useful to focus on what’s happening. Dashboards are terribly difficult to get right without personalization which itself complicates the experience and adds another “to-do” to the never ending to-do list. I prefer to land at the root of my source tree. Developers live inside source. When I come home, I want to see my home before I’m told what’s been fixed inside and before someone nags me about what broke when I was gone.

Code

I love that GitHub displays a folder’s README file under the code navigation block and that it renders Markdown. At the root/hompage, I intend to seed a README with my company’s tenants of maintaining a quality codebase. This will be reinforced every time a developer browses to the repository. READMEs at various levels of depth beneath the root are a great way to capture high visibility organizational and project-specific information. GitHub’s slide-screen navigation is slick as heck. Its easy to pop in and out of folders with the forward and back buttons on the mouse. I think they nailed the navigation. I also like they way they render code; its easy on the eye and they seems to support lots of languages through the Pygments library.

Organization

You get it…less is more. We live in an Apple world of design. A example of poorly designed navigation is SourceForge. I’ve seen projects with 9 tabs, some of which drop-down to reveal yet more options!

It seems that repository hosts are trying to serve two populations with somewhat competing needs: open source projects and businesses. Take GitHub. I would happily trade the “Network” and “Stats & Graphs” tabs for a “Downloads” section. The former are fun and interesting, but in my opinion lack business value. If you are in need of these metrics then likely you are disconnected from the real progress of your organization or you’re a micromanager. Aside from a “Code” tab (why would you call it anything but that??) I think all high-level units of navigation should be optional (think checkboxes in admin section). This forces some hard thinking about how best to group features.

Bug Tracker, Wiki

Some hosts have built-in bug trackers, some provide this functionality as an “add-on”, and some let you hook into other bug tracking systems. I’ll take a no-frills, built-in system any day. Psychologically, there’s something valuable about seeing bugs aside source. The dev team/test team dichotomy is under attack for good reasons. Developers need easy access to the bug database. They should be filing bugs and they should treat bugs as normal process in their coding workflow. The bug tracker is as much a first-class citizen as the source itself. The two are interrelated and it makes tons of sense to manifest that in the repository. Besides, its time-consuming managing multiple systems.

A wiki is natural place to put documentation. If you’re not using a wiki, then likely you’re hosting docs on some server. It could be as low-tech as a document fileshare. Maybe you installed SharePoint (sorry, I just puked. When I left Microsoft I vowed never to use two products. SharePoint was one. I’ll let you guess the other). In 2007 I would have accepted the usability argument against wikis - that its simply easier to create documentation in a rich-client like Word. But times have changed and these systems have gotten better. GitHub uses gollum for wikis. Its simple and effective and doubly intuitive since the wiki is just a rendered Git repository. As I said before, its time-consuming managing multiple systems. Why not put your technical documentation next to the “technical” that’s being documented? =)

User Adoption

Lets face it, that new open source project you read about on Hacker News has a 80% chance of being hosted on GitHub. It’s the wisdom of crowds. More and more my Google searches land on a GitHub repository. There are lots of people invested in GitHub’s success.

IRTFMAIS

2012-04-12T00:00:00-04:00

I Read The F***ing Manual And It Sucks

from xkcd

R Source on GitHub

2012-04-10T09:50:00-04:00

I added R source code v0.49 to v2.15.0 to a GitHub repository: r-source
Each release is tagged by version number.
This is an easy and accessible way to browse R source and diff with prior version. I couldn’t find a suitable alternative.
A tarball via Apache directory listing via CRAN mirror via the ____ (insert sarcastic adjective) R-project website is not a suitable alternative.
I will keep the repository updated as new versions of R are released.

R, I Love You

2012-04-05T00:00:00-04:00

It is easier to critique than it is to create. I write this post with much gratitude for R, the R community and particularly R-Core who are paid $0 to bring us R. I’d like to offer an idea and I’m wondering if people are interested in rallying around it.

Julia, I’m in committed relationship

You might have caught the post titled “Julia, I Love You”. It’s the top article on Rbloggers. Perhaps you had the same reaction I did. I read the material, repeated “wow” a few times, and slipped into a contemplative space. Am I betting on an outdated technology? I slapped myself (figuratively) and snapped back to reality. I vaguely remember when Revolution Analytics released side-by-side performance figures there was pushback about an apples-to-oranges comparison. Some tests had to be reworked (or am I just make that up?). People have added comments to the Julia post with performance fixes to the R code used to benchmark against Julia. And in the end, languages come and go but R has withstood the test of time.

I use R | Julia because. . .

Why do people use R? In my (informal, anecdotal, not rigorous, no medals of honor conferred) survey, the reasons people use R are:

It’s free
There are lots of packages on CRAN
Its easy to code

Food for thought:: Julia has #1 and #3 covered and #2 is just a matter of time if the adoption curve is upward sloping. All things being equal…

Performance IS an issue

Something is bugging me. What’s bugging me is how defeated I feel when I see R benchmarked against anything. I see the figures and I think, “it is what it is.” I’m sure the R-defenders will point to all sorts of stats and tell me that I’m wrong. I’ll still shrug. I use R on a daily basis and it consistently feels like an order of magnitude slower than my internal benchmark (lots of hand-waving there). Yeah, I know I can use C++. Its not my cup of tea. If it were I would just use C++ and I wouldn’t try to shim it into R. I’m using R because I want to write in R. I do byte-compile all packages, which helps a little.

Also, R is lacking on multicore. On Windows its not possible to run tasks in parallel, in-process (if you have gotten this to work, please let me know). Out-of-process communication is slow and there’s the memory tax of maintaining multiple instances of R. Most of the time all cores but one are idle. Tech moves fast. If we don’t challenge ourselves then we decay.

R, I Love You, so here’s my idea

Stop writing new features. R has enough features. Lets make 2.16.0 a performance fix release. This is not an uncommon practice. Instead of treating performance as something we tackle incrementally, lets steer our open source mindshare towards the single goal of performance for a release or two. Lets excite developers who get their jollies from optimization.

Heck, lets pay for it if we have to. There’s an R Foundation, right? Kickstarter has been enormously successful in raising funds for projects that people care about. If a team on Kickstarter can raise $1M for a video game that has a limited shelf life, surely we can raise capital for a tool that some of us practically live in. People will donate because they stand to benefit.

We can organize around 3 broad categories:

High performance, multi-core math libraries
JIT
Lightweight, in-process task parallization on all major platforms

So that’s my idea. Thoughts?

How R Searches and Finds Stuff

2012-03-29T00:00:00-04:00

Or…
How to push oneself down the rabbit hole of environments, namespaces, exports, imports, frames, enclosures, parents, and function evaluation?

Motivation

There are a few reasons to bother reading this post:

Rabbit hole avoidance
You have avoided the above mentioned topics thus far, but now it’s time to dive in. Unfortunately you speak English, unlike the R help manuals which speak “Hairy C” (imagine a somewhat hairy native C coder from the 80s who’s really smart but grunts a lot…not the best communicator).
R is acting a fool
Your function used to work, now it spits an error. Absolutely nothing about this particular function has changed. You vaguely remember installing a new package, but what does that matter? Unfortunately my friend, it does matter.
R is finding the wrong thing
You attached the matlab package and call sum() on a numeric matrix. The result is a vector of column sums, not a length 1 numeric. This messes up everything. What were you thinking trying to make R act like Matlab? Matlab is for losers (and rich people).
You want R to find something else
You like a package’s plotting function. If you could intercept one call within the function and use your own calculation, it would be perfect. This seems like black magic to you, but something is strange about maintaining a full copy of the function just to apply your little tweak. Welcome to the dark arts.
Package authoring
You have authored a package. How does your kid plays with the other kids in the playground?

Where does R put things?

Everything is R lives in an environment. Ultimately, we’re trying to figure out which environment something lives in, and how we get there (or how we got there). An environment, like everything else in R is an object. Objects hold stuff. Environments are specialized, they can only hold two things:

A frame
This is just a collection of named objects. What’s a named object? Everything in R is an object, so it can be a function, a numeric, a character, a logical, etc. And these objects have names like myFunction, myNumeric , myCharacter, myLogical. When you type myVar = "charlie" at the command prompt you create a character object that holds the string "charlie" and you’re calling that object myVar. Since everything in R lives in an environment and the frame is the place where an environment holds objects, then the object you just created called myVar lives in a frame within some environment.
The environment’s owner aka the enclosing environment.
This is just a reference to another environment.

As you can see from the visualization above, the chain of enclosing environments stops at a special environment called the Empty Environment. You can access this object by executing emptyenv() in R. And given an environment object, you can query the object for the two things that matter: the environment’s owner and the objects in the frame.

A Fib About Owners and Pointers

Before you hit send on that flame mail I acknowledge a technical misdirection that I have and will continue to make. I use the concepts of ownership and containment loosely. I will say own or contain when I really mean pointer. If pointer means nothing to you then skip to the next section.

I will continue to talk about environments as owning objects, particularly functions. In truth functions are instructions stored somewhere in memory, and they are accessed by symbols in lookup tables that, when found, give a pointer to them. The core concepts of this article are agnostic to pointers and understanding pointers is unnecessary to achieve mastery of the search mechanism in R. In fact, R tries really hard to hide pointers. So yes it pains me to be technically imprecise, but I’m trying to keep things simple because most people can understand an ownership relationship and we have a lot of ground to cover.

Play time with Environments (don’t skip me)

# environments are just objects.  lets create one.
> myEnvironment = new.env() 

# print it out...
> myEnvironment 
<environment: 0x0000000006ce0920>

# every environment (except R_EmptyEnv) has an enclosure.
# Who's myEnvironment's enclosure?  It's "R_GlobalEnv" - find out using parent.env()
> parent.env( myEnvironment ) 
<environment: R_GlobalEnv>

# Who's R_GlobalEnv's enclosing environment? 
# Its the environment called "package:stats" (in my installation, might be different on yours)
> parent.env( parent.env( myEnvironment ) ) 
<environment: package:stats>
attr(,"name")
[1] "package:stats"
attr(,"path")
[1] "C:/R/R-2.14.1/library/stats"

# Here's two other ways to ask the same question. 
# This R_GlobalEnv must be special if it can retrieved using the identifier
# .GlobalEnv AND a function globalenv().  We'll discuss R_GlobalEnv later.
> parent.env( .GlobalEnv ) 
<environment: package:stats>
attr(,"name")
[1] "package:stats"
attr(,"path")
[1] "C:/R/R-2.14.1/library/stats"
> parent.env( globalenv() )
<environment: package:stats>
attr(,"name")
[1] "package:stats"
attr(,"path")
[1] "C:/R/R-2.14.1/library/stats"

# The empty environment is accessed using emptyenv() 
> emptyenv()
<environment: R_EmptyEnv>

# Why does myEnvironment have a funky name 0x0000000006ce0920? 
# That's just the location of the environment in memory.
# We can add a friendly name by assigning a "name" attribute.
# Unfortunately R doesn't replace the funky name with the friendly name when printing.
# We can use the environmentName() function to verify our cool name 
> attr( myEnvironment , "name" ) = "Cool Name" 
> myEnvironment 
<environment: 0x0000000006ce0920>
attr(,"name")
[1] "Cool Name"
> environmentName( myEnvironment ) 
[1] "Cool Name"

# lets create a numeric object
> myValue = 5

# Unless you try hard, when you create an object it is automatically placed in the 
# "current" or "local" environment, accessible using environment()
> environment() 
<environment: R_GlobalEnv>

# And we can query an environment for all objects in the frame using ls().
# Here we verify that objects myEnvironment and myValue are both placed in the local environment, R_GlobalEnv
ls( envir = environment() )
[1] "myEnvironment" "myValue"      

# We can override the default behavior and create an object in an environment other than the local environment.  
# To do this use the assign() function.  Here we create variable "myLogical" inside myEnvironment.
# We use ls() to verify that there was nothing in myEnvironment before the assignment, 
# and again ls() verifies that "myLogical" is inside myEnvironment after the assignment
> ls( envir = myEnvironment )
character(0)
> assign( "myLogical" , c( FALSE , TRUE ) , envir = myEnvironment )
> ls( envir = myEnvironment )
[1] "myLogical"

# We can retrieve any named object from any given environment using the get() function
> get( "myLogical" , envir = myEnvironment )
[1] FALSE  TRUE

# How could I have known that myEnvironment's enclosure would be R_GlobalEnv before I created the object? 
# Once again, R uses the local environment as the default value.  
# You can change an environment's enclosure using the replacement form of parent.env().
> myEnvironment2 = new.env()
> parent.env( myEnvironment2 )
<environment: R_GlobalEnv>
> parent.env( myEnvironment2 ) = myEnvironment
> parent.env( myEnvironment2 )
<environment: 0x0000000006ce0920>
attr(,"name")
[1] "Cool Name"

# Here's another way to understand the "current" or "local" environment
# We create a function that calls environment() to query for the local environment. 
# When R executes a function it automatically creates a new environment for that function.
# This is useful - variables/objects created inside the function will live in the new local environment.
# We call Test() to verify this.  We can see that Test() does NOT print R_GlobalEnv. 
# We didn't created any objects within Test().  If we had, they would live in the "0x0000000006ce9b58"
# environment while Test() is running.  When the function completes executing, the environment dies.
> Test = function() { print( environment() ) } 
> environment()
<environment: R_GlobalEnv>
> Test() 
<environment: 0x0000000006ce9b58>

# And why not...who's the enclosing environment?
# There's more than meets the eye here.  We'll go deeper in a bit...
> Test = function() { print( parent.env( environment() ) ) }
> Test()
<environment: R_GlobalEnv>

Short Answer: How R Searches and Finds stuff

Have you followed along with the code above? It seems that environments are not just static repositories of objects. When R executes an expression, there is always one local or current environment. Maybe its easier to think of this as the active environment, in contrast to the other environments which are inactive. Or perhaps its more intuitive to think of an expression executing “within” a particular environment. The point here is that at any moment R can ask “hey, what’s the local environment.” R asks this questions a lot. In fact, it asks this question every time it needs to find a named object. We saw that R creates a new local environments every time it runs a function. So when we run any decently involved piece of code, functions call other function and environments spawn and die.

Imagine we just freeze the system at any one expression. When R goes searching for the names in that expression, it first looks at the objects within the local environment. If the object is not found by name in that environment, then R searches the enclosing environment of the local environment. If the object is not in the enclosure, then R searches the enclosure’s enclosure, and so on. That’s how R searches and finds stuff; it traverses the enclosing environments and stops at the first environment that contains the named object.

Satisfied? I didn’t think so. Lets roll…

Map of the World (follow the purple line road)

We just said that R searches through the chain of enclosing environments to find named objects. Its sort of like a treasure hunt that is limited to a single direction. What we need for this treasure hunt is a map of the world!

This graphic shows the state of all environments when you first startup R. Each box represents a unique environment. The solid purple line represents the enclosing environment relationship. I’ll explain the dotted purple line in a bit. For now, consider it a relationship that’s similar to the enclosing environment.

The Global Environment

I said that R_GlobalEnv is a special environment and you can see that it is colored green in the map. Green means start. The global environment is precisely the environment that you start at when you launch R. It is your current or local environment when R launches. If you make an assignment at the prompt, the named object is stored in R_GlobalEnv.

# the ls() function shows us all objects defined in a given environment.
# In this case we're using the identifier .GlobalEnv to refer to the global environment
# Here we can see that upon startup the global environment contains no objects
# but after we assign myVariable, the global environment contains an object with that name
> ls( envir = .GlobalEnv ) 
character(0)
> myVariable = 0 
> ls( envir = .GlobalEnv )
[1] "myVariable"

# be careful with the environment() function.  It might seem wrong that this returns NULL
# but if you read the documentation you'll see that environment() takes a function as input.
# myVariable is not a function, its a numeric.  The purpose of environment() is not to tell you
# an object's owner.  More to come...
> environment( myVariable )

The Search List

In R, the “search list” is the chain of enclosing environments starting with R_GlobalEnv and ending with R_EmptyEnv. I like to think of it as the main highway on our map. This is the highway that R drives down when we start in R_GlobalEnv. All roads in our world eventually lead to this highway. You can obtain the search list by typing search() at the prompt:

> search() 
[1] ".GlobalEnv"        "package:stats"   "package:graphics" "package:utils" "package:datasets" 
[6] "package:grDevices" "package:methods" "Autoloads"        "package:base"

Package v. Namespace v. Imports Environments

If you stare at our map above for enough time you might notice that every R package has 3 associated environments. If you think that this is confusing then you are blessed with common sense. This drove me crazy when I first encountered it. Trust me for now that the only tricky part about this is the naming convention, otherwise this trifecta is useful and well-designed.

Here’s a breakdown, left to right:

package environment
This is where a package’s exported objects go. Simply put, these are the objects that the package author wants you to see. These are most likely functions. Typically a package is published that provides useful functions related to some topic or domain. In traditional Object Oriented Programming (OOP), this is analogous to a “public” class or method. If that means nothing to do you then ignore it.
namespace environment
This is where all objects in a package go. This includes objects the package author wants you see. It also includes objects that are not meant to be accessed by the end-user. The latter, the “hidden” objects (they are not really hidden, you can access them if you’d like) facilitate the “visible” ones. For example, a function HardCalculation() might offload some complicated text formatting tasks to function MakeResultsPretty(). The author doesn’t want you to call MakeResultsPretty(), its sole purpose is to format the results that are idiosyncratic to HardCalculation(). In OOP this is analogous to a “private” or “internal” class or method.

You might be thinking “wait, so objects the author wants me to see are in BOTH the package environment and the namespace environment?” Yes and No. Yes, both environments have a frame that lists objects of the same name, but no there is not two copies. Both environments have pointers to the same function. If that makes no sense to you then think of it as two copies - it honestly doesn’t matter. This may seem like an odd arrangement (two pointers, two copies - your pick) but its use will become apparent shortly. This is also why there is no easy way to query an object for the environment that owns it. Its possible that two or more environments own the same object.
imports environment
This environment contains objects from other packages that are explicitly stated requirements for a package to work properly. Most packages published on CRAN are not islands; they build on functionality provided in other packages. Take ggplot2 for example. You can see on the CRAN page in the “Imports” section that it requires plyr among other packages. I suggest using the screenshot below since the package could change in a way that breaks my example. The imports:ggplot2 environment contains all objects in the plyr package.

Imports v Depends

You might have been confused seeing a Depends and an Imports section. If Imports states a package’s requirements, then what does Depends do? This is a poor naming convention. The Depends section also lists packages that ggplot2 requires. The difference between Imports and Depends is where the requirement is placed on our map of the world. Because our map specifies the path R takes to find objects, there are consequences to specifying a requirement in Imports versus Depends in terms of how R finds the dependency.

If the package is specified in Imports, then the package contents will go into the “imports” environment. In the case of ggplot2, the objects in the plyr package will appear in the imports:ggplot2 environment. Notice also that plyr does not have a package environment. Its nicely tucked away inside the environment imports:ggplot2. The dotted purple line will be explained later.

If a package is specified in Depends (i.e. reshape package), then the package is loaded as it would be if you called library() or require() from the R prompt. That is, the package, namespace, and imports environments are created for the dependency and placed on our map. The reshape package is attached before ggplot2 and the package:reshape environment becomes package:ggplot2’s enclosing environment.

So who cares? Is the choice between Depends and Imports arbitrary? Its not. The library() command (or generally attaching a library) places the package environment under R_Global. More precisely, the package environment becomes R_Global’s enclosing environment. R_Global’s old enclosure now encloses the package environment. You can see this in the diagram below where we have loaded the package reshape2 which is a re-write/upgrade of the original reshape package.

Both reshape and reshape2 contain the function cast. Lets say (I’m making this up) that ggplot2 has a function called FunctionThatCallsCast(). As you can guess, this function calls the cast() function. Without knowing any details of how R finds stuff, lets just follow the “purple line road”. We travel from to 1 and 2 and find FunctionThatCallsCast(). Remember, the package and namespace environments both reference a package’s public-facing functions. We execute that function and now we need to find cast. We travel from 3 to 5 searching for cast. We find cast at 6 and stop. But this is the wrong cast. This is cast in package reshape2, but ggplot depends on the cast in reshape. This could have dire consequences depending on the differences between cast in reshape and reshape2.

The better solution would have been to stuff reshape’s cast() function into imports:ggplot2 using the Imports feature. In that case, we would have travelled from 2 to 3 and stopped. Now you can see why the choice between Imports and Depends is not arbitrary. With so many packages on CRAN and so many of us working in related disciplines its no surprise that same-named functions appear in multiple packages. Depends is less safe. Depends makes a package vulnerable to whatever other packages are loaded by the user.

namespace:base

We haven’t mentioned the fact that all imports:<name> environments have namespace:base as their enclosure. Think of this a freebie for creating a package. Since the base functions are used frequently, they are most likely a dependency for any package (or a package’s imports). Without namespace:base where it is, R would have to go hunting quite far to find package:base. There’s a big risk that another package has a function of the same name as a base function. A package author cannot know a-prior when you intend to attach her package nor that you have decided to write your own version of a base function. So do as you like, a package author can expect that R will find the base functions immediately after Imports. There’s no chance of corruption.

The Curveball (the dotted purple lines)

Functions, like all objects, are housed inside environments. However, functions themselves have a property which is a pointer to the environment in which they should run. When you create a function, that property is automatically set to the environment in which the function was created. So the environment that houses a function and the environment that the function will run in is one and the same.

What do we mean by “the environment that a function will run in?” We said earlier that executing a function creates a new environment specifically for that function. We also said that all environments have an enclosing environment. So what environment is the enclosure of the function’s new environment? This is what is specified by the function’s environment property. This is “the environment that a function will run in.” Its not necessarily the environment that owns the function. It is controlled by the function’s environment property.

We can get a function object’s environment property using the environment() function. For example:

> MyFunction = function() {} 
> environment( MyFunction ) 
<environment: R_GlobalEnv>

And when we run MyFunction() and R is executing lines of codes inside that function, the environments look like this:

By default, R sets a function’s environment property equal to the environment where the function was created (the environment that owns the function). However, its not necessary that a function’s executing environment and the environment that owns the function are one and the same. In fact, we can change the environment to our liking:

# notice how environment(MyFunction) no longer returns R_GlobalEnv
> MyFunction = function() { } 
> newEnvironment = new.env() 
> environment( MyFunction ) = newEnvironment 
> environment( MyFunction ) 
<environment: 0x000000000e895628>

# Another way to see a function's environment property is to just print 
# the function. The environment will appear at the bottom of the printed function 
> MyFunction
function() { } 
<environment: 0x000000000e895628>

# Here we do the same for the standard deviation function
> environment( sd ) 
<environment: namespace:stats> 
> sd 
function (x, na.rm = FALSE) 
{ 
  ... (removed for brevity) 
} 
<bytecode: 000000000E7F2EA0>
<environment: namespace:stats>

# Can you figure out what's going on here? 
# When run, FromLocal's enclosing environment is the MyFunction environment.  That's where 
# FromLocal was created and that's what R does by default.
# When R searches for the object "age" within FromLocal it looks to the MyFunction environment,
# picks-up age = 22 and adds 1 to that. 
# -
# When run, FromGlobal's enclosing environment is R_GlobalEnv because 
# we assigned the function's environment property to R_GlobalEnv.
# When R searches for "age" within FromGlobal, it looks at the enclosing environment which is 
# The Global environment, and picks up age = 32 and adds 1 to that.  
# -
# The environment of NoSearch() already has 
# the age object and does not need to search its enclosing environment(s).
> age = 32 
> MyFunction = function() 
+ { 
+     age = 22 
+     FromLocal = function() { print( age + 1 ) } 
+     FromGlobal = function() { print( age + 1 ) } 
+     NoSearch =  function() { age = 11; print( age + 1 ) } 
+     environment( FromGlobal ) = .GlobalEnv 
+     FromLocal() 
+     FromGlobal() 
+     NoSearch() 
+ } 
> MyFunction() 
[1] 23 
[1] 33 
[1] 12

This explains the dotted purple lines in our map. If you inspect the environment property of the functions within the package:<name> environments you’ll see that they all point to the namespace:<name> environment. Check it out:

# get the standard deviation function within package:stats and
# inspect the function's environment property.
# Notice that it points to the namespace:stats environment
> statsPackageEnv = as.environment( "package:stats" ) 
> sdFunc = get( "sd" , envir = statsPackageEnv ) 
> environment( sdFunc ) 
<environment: namespace:stats> 
> statsNamespaceEnv = environment( sdFunc ) 
> sdFunc2 = get( "sd" , envir = statsNamespaceEnv ) 
> environment( sdFunc2 ) 
<environment: namespace:stats>

# An easier way to get a namespace environment
> statsNamespaceEnv = asNamespace( "stats" ) 
> statsNamespaceEnv 
<environment: namespace:stats>

So in essence, the package environment is just a pass-thru to the namespace environment. The package environment says “I don’t know what to do, ask my functions”. And when we ask the functions they all say “when you execute us create a new environment whose enclosure is the namespace environment.” More precisely, the functions are just offering up their environment property . We might as well make those dotted lines solid:

Incidentally, this is another explanation for why there’s no easy way to query an object for the environment that owns it. When we are executing in an environment, we are interested in the objects it owns because we might be looking for one of them. When we find a function we need to know which environment to execute it within. But its not important in our workflow to identify an arbitrary object’s owning environment.

If your head is spinning then I encourage you to pause and re-read this entire section. Function execution is the most complex piece of the puzzle.

Passing Functions

Feel free to skip this section

Its because functions have an environment property that they can be passed around. Passing a function to another function is a mind-boggling (albeit powerful) feature. I’m not going to explore this too much. At a high level you can think of it as follows. If a function FunctionA( someOtherFunction ) takes another function someOtherFunction as a parameter then FunctionA must have some variability in the way it runs. That variability is governed by the implementation of someOtherFunction. When we construct someOtherFunction, we expect it to run in a particular way. someOtherFunction should have access to the objects in the environment in which it was constructed. That expectation doesn’t change when the function is handed-off to FunctionA . But R creates a new environment for FunctionA. Thankfully that’s not a problem. When someOtherFunction is finally run R looks to the function’s environment property and executes within that environment, not within FunctionA’s environment. So the integrity of our expectation is upheld. In fact, FunctionA can pass someOtherFunction to FunctionB which in turn can pass the function to FunctionC and it has no consequence on how someOtherFunction will run. That’s the magic of a function’s environment property.

That Creepy Caller

The search mechanism does not use the call stack. The call stack is the sequence of function calls that has gotten you to wherever you currently are in the calculation. For example, FunctionA calls FunctionB which in turn calls FunctionC. The call stack just places each of those functions on top of one another in the order in which they were called. Lets say FunctionC needs to execute FunctionD. The wrong way to think about the search mechanism is to follow the callers. That is, if FunctionD is not defined in FunctionC’s executing environment, then look at FunctionB’s executing environment and if not found there then look at FunctionA’s executing environment. The right way to think about the search mechanism is to ask “who owns Function C?” If the owner knows nothing about FunctionD, then maybe the owner’s owner does, and so on.

Unfortunately, the call stack is more intuitive than the chain of enclosing environments. Just remember, whenever R is evaluating a statement the system is simultaneously at the top (or bottom if it’s easier to visualize that way) of two important chains of environments. One is the chain of enclosing environments which is involved in the task of scoping (i.e. where to look next for variable names not found in the frame of the current environment). This is the chain we care about. The other chain is the call stack, which is produced by the sequence of function calls. You can ignore this chain. There are scenarios where it’s necessary to look for a variable via the call stack, but to accomplish that you have to use some special functions in R. Those scenarios are beyond the scope of this article.

A word of caution: R (and some R literature) uses the term “parent” in context of both chains. There’s the function parent.env() which we already know and parent.frame() which is used to interrogate the call stack. This is certainly confusing and its a historic slip-up. The term “parent” should not be used as a substitute for enclosing environments. It should only be used with the call stack.

Finally, How R searches and finds stuff

So, finally, how does R search and find stuff? R just follows the purple line road in our map above. Lets follow along with an example

Lets say we’re looking for function ggplot. We start at R_GlobalEnv. If ggplot is not in the global environment, then it must be in a package. So R travels down the search list looking for ggplot. This is simply the chain of enclosing environments starting with R_Global. R ultimately find the function in one of the package environments. Although ggplot is found within the package environment, R executes ggplot within the namespace environment as described in the prior section. In this case, we’ve found ggplot in package:ggplot2 and we execute the function within namespace:ggplot2.

Lets say ggplot calls another function MyFunction. A few things can happen:

If MyFunction is defined within ggplot, then we find it immediately since R checks the local environment first. In this case the local environment is the environment created to run ggplot
If not found, then R looks to the enclosing environment of MyFunction’s executing environment which is namespace:ggplot2. If we find MyFunction here, then it’s a case of a package function calling another function in the same package.
If MyFunction is not in the namespace:ggplot2, then R checks the enclosing environment of the namespace environment which is the imports environment. This gives ggplot an opportunity to find MyFunction within a set of explicitly defined package dependencies. This is like ggplot finding a plyr function in our example above.
If MyFunction is not in the imports environment, then we check the enclosing environment of the imports environment which is namespace:base. A base function (i.e. sd() for standard deviation) would be found here and the search would be complete.
If MyFunction is not found in namespace:base, then we are back to the search list. We start by checking R_GlobalEnv. Its unlikely that MyFunction is in R_GlobalEnv. It would be poor practice for a package to expect the user to define some function in the global environment. However, the user could take this as an opportunity to intercept the search by defining her own version of MyFunction in the global environment.
If MyFunction is within a package that’s a dependency of ggplot2 and that dependency is specified in Depends rather than Imports, then the search list is where we would find MyFunction. This is like ggplot looking for a function in the reshape package in our example above. We would hope that no other package has defined the same function and is attached closer to the global environment (as in our reshape2 example above)

All-in-all you just have to determine what the “current” or “local” environment is and following the enclosing environments (the purple arrows) until you find the object you are looking for. Rinse and repeat.

Qualitative Comments

I believe that the search and find mechanism is an adequate design given that R is an interpreted, weakly typed language that supports attaching multiple packages at-will. If we are executing outside of a package (as in R_GlobalEnv) it enables us to find functions inside packages. If we are inside a package it allows the package functions to find the specified dependencies. If we are inside a package or a package’s imports (dependencies), then we have a buffer of base functions before we plunging into the search list. Also, the design ensures that we terminate at R_EmptyEnv if a named object cannot be found, no matter where on the map we are.

All of that said, its still complicated. When I’m debugging a search-and-find issue it takes a lot of brainpower to figure out what’s going on. Don’t beat yourself up if the same is happening to you.

Skip the search-and-find

If you know exactly which package contains the object desired then you can reference it directly using the :: operator. Simply place the package name before the operator and the name of the object after the operator to retrieve it.

# use :: to get sd
> stats::sd 
function (x, na.rm = FALSE) 
{ 
    ... ( omitted for brevity )
} 
<bytecode: 000000000511D608> 
<environment: namespace:stats>

If the object is not exported or you are unsure, then you can use the ::: operator (notice the extra colon).

# use ::: to get Wilks
> Wilks 
Error: object 'Wilks' not found 
> stats:::Wilks 
function (eig, q, df.res) 
{ 
    ... ( omitted for brevity ) 
} 
<bytecode: 00000000050FE280> 
<environment: namespace:stats>

This operator searches the namespace environment for the given object (as we discussed, non-exported objects do not appear in the package environment, only in the namespace environment). You can validate that by looking at the definition of ::: (remember to include the backticks).

# view the ::: operator function
> `:::` 
function (pkg, name) 
{ 
    pkg <- as.character(substitute(pkg)) 
    name <- as.character(substitute(name)) 
    get(name, envir = asNamespace(pkg), inherits = FALSE) 
} 
<bytecode: 00000000073BAEA8>
<environment: namespace:base>

Thanks

I’d like to thank Josh O’Brien who reviewed a draft version of this post and provided solid feedback. His comments and challenges directly improved the quality of this article. In some cases I lifted text verbatim from his emails (with his permission of course). I am grateful to him for being so generous with his time. I’d also like to thank the R community on StackOverflow for being patient with numerous questions that I’ve posted about topics herein discussed. That community continues to be the absolute best way to get answers about R. Finally, I thank John Chambers for writing the R programmer’s must-have book Software for Data Analysis.