Allen's lambda syntax proposal

Jon Zeppieri jaz at
Fri Dec 5 23:12:14 PST 2008

On Fri, Dec 5, 2008 at 11:07 PM, David-Sarah Hopwood
<david.hopwood at> wrote:
> Maciej Stachowiak wrote:
>> On Dec 5, 2008, at 10:00 AM, Jon Zeppieri wrote:
>>> A label is an escape continuation.  Once control has returned past the
>>> point where the continuation was captured, it's dead, and it can't be
>>> resumed.
>> So return from a lambda is sometimes but not always a runtime error?
> That in itself does not seem much of a problem (it doesn't seem to be
> in Smalltalk or E).
>> Other times it can return through multiple levels of function calls
>> without raising an exception? That seems pretty bad for ease of
>> understanding and for performance of implementations.
> I agree, although I would express this as a safety issue: the safety
> hazard is that you may call a lambda without expecting it to perform
> a jump within the calling scope. The performance issue is that *all*
> calls that are within the scope of a labelled statement or loop must
> check for an escape.

I don't get it.  What issue is raised by return-to-label that isn't
already raised by exceptions?  They're practically the same thing,
only return-to-label is *easier* to analyze statically, because
'return' can only jump to a label that is lexically (not just
dynamically) in scope.

> There is a possibility for solving both of these issues while still
> allowing all of the suggested uses of lambdas. It involves permitting
> a given call to perform an escape (that is, break, continue or return)
> only if it is explicitly marked as being able to do so. If an unmarked
> call would escape, then it instead throws an exception.
> For example (syntax intended only as a strawman; I know it is
> incompatible to add an 'escape' keyword):
>  CallExpression :
>    ...
>    'escape' CallExpression Arguments
> Then a user-defined 'while' could be written as:
>  const _while = \(cond, body) {
>    // escapes from 'cond' are intentionally disallowed;
>    // only 'body' can escape.
>    if (cond()) { escape body(); escape while(cond, body); }
>  };

Can the call to cond throw?  If so, what did you gain from this?


More information about the Es-discuss mailing list