Jim,

> > What I don't like:
> >
> > 1. Functions as assignable objects (aka first class
> > function). I see the cost but not the benefit.
> > 2. Function ambiguity. A single function can be a standalone
> > function, a method on object, and an object constructor.
> > 3. Invisible context. An attribute reference in a function is
> > determined by the call path rather than the function
> > definition.
> > 4. The runtime cost of name resolution in such a complex
> > environment.

I suspect that 1, 3 and 4 may be related, and all reflect on the
concept of closures.

Closures go back to languages like Lisp and Algol 68. They can be
implemented efficiently by introducing a closure element into the
runtime/VM. The closure element can be thought of as a heap allocated
(partial) stack frame. If the runtime maintains a "display" array,
variable references in a function can be resolved at compile time to
simple pointer arithmetic:
Var *closurevar = &(display[level][offset])

A description of traditional closure implementation can be found in
chapter 2 of this paper:
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.5.997

> Have you read Douglas Crockford's book?
> http://oreilly.com/catalog/9780596517748/

A summary is here:
http://assets.expectnation.com/15/event/3/JavaScript_%20The%20Good%
20Parts%20Presentation%201.pdf

In his view, closures are rather core to JavaScript.

Paul