Proposal: opt-out local scoping

Mark S. Miller erights at
Fri Aug 29 19:25:05 PDT 2008

On Fri, Aug 29, 2008 at 6:45 PM, Felix <felix8a at> wrote:
> ihab.awad at wrote:
>> Also, you seem to be asking for an explicit way to say, "this variable
>> does not respect Tennent correspondence; I know I am doing this and I
>> have a good reason" --
> I'm suspicious of Tennent correspondence, because I think simple
> variations of the statement do not match anyone's expectations.
> if I understand correctly, Tennent correspondence says:
> t1: any expr should be equivalent to
>         (function() {expr}) ()
> and one of the difficulties is, what if expr has control-flow
> statements, such as break or return.  another difficulty is, what if
> expr has lexically-scoped statements, such as local variable declarations.

Since ES is not an expression language, it's useful to divide the question into

* TC for expressions
   expr equiv (function(){return expr;})()
   ES violations: this, arguments.
   'this' breakage can possibly be addressed with '.bind(this)' as in
my previous message.
   expr equiv (function(){return expr;}).call(this)

* TC for blocks
   {stats} equiv (function(){stats})();
   Same issues re this, arguments
   Additional ES violations: return, break, continue, var hoisting

Note: The above litany of problems are not fixable in ES. But we
should try to avoid digging this hole any deeper.

> assume N is a unique generated symbol.  Tennant correspondence could
> also be stated as
> t2: any expr should be equivalent to a function in the same scope
>        function N() {expr}
>     and a call to that function
>        N()
> that isn't true in any practical language I know,

Smalltalk, Scheme, Self, E, AmbientTalk/2, and apparently Scala. In
general, I'd expect it to be true in any language in which closures
are used to do all control abstraction, which probably includes a
large number of languages I haven't mentioned. (Note: E currently has
one minor TC violation which we consider to be a bug and plan to fix.)

> and it seems unhelpful
> to say that function declaration is broken in all of them.  I don't
> think anyone expects that you can extract arbitrary pieces of code into
> a separate function without fixing up control-flow and scoping.
> and part of the usefulness of functions is that they _do_ introduce a
> discontinuity, which lets you express things that are more difficult to
> express without it.

Smalltalk, Scheme (at least prior to R6RS), and Self are widely and
properly regarded as among the least broken programming languages that
have ever been designed. The early JavaScript set us on a path worth
rescuing largely due to Brendan's good taste in appreciating the
virtues of Scheme and Self.


More information about the Es-discuss mailing list