You can open heap profiler, type inspect(variableName) and reveal it in the heap snapshot. That one would show you all the retainers. Please try it out and see if closures are explained in a reasonable manner there.

The common we likely all see trip users up is as follows:

```
class Apple {}
class Orange {}
var apple = (function() {
  var red = new Orange();
  var green = new Apple();

  function theOther() {
    red;
    green;
  }

  return function theInner() {
    return green;
  }
}())

window.a = apple();
```

We know that `red` will be retained by `theInner` via the context which is closed over by both `theOther` and `theInner`.


The Memory profiler informs us (correctly) that:

`red` is being retained by the `context` which is retained by `theInner()`

I notice this often leaves people new to these concepts in a bad place, unsure how to proceed. It seems quite common to forget/not know the relationship between `theOther` `theInner` and the `context`.

One idea, would be to allow inline exploration of the `context` within the heap profiler.

Now it is possible (if a breakpoint is set) to explore the `context`, but not from the memory profiler

---

In addition, a glossary of terms used in the heap profiler may be of value.

Some related ramblings: I have had some success teaching these concepts by reframing the problem from containment/retainers to "who owns the some given state" "how long does the owner live" when you pass state around "how long does that thing need the state." Just some general OO principles... but this tends to give developers a mental model that sets the up for success, minimizing memory leaks and re-entrant state mutation bugs.

Now, it is obviously out of the scope of this issue to add those concepts to the language. But maybe it will spark some ideas on tooling/debugging that may help?

For example,  to the `inspect(varName)` you mentioned is handy if you have a heap snapshot.  But while in the debugger, that information (retainers) is still quite valuable. Could it also be surfaced?

*note: what I guess I describe is not that dissimilar to rusts stance of ownership/borrowing*